Read Apple-Mails strange gpg

Using gpg to secure your communication is great. It would also be great to end this topic at this point but I guess an unwritten law in end user cryptology is: "It would not be secure if it was not somehow obscure and user unfriendly."

The Problem:

--Apple-Mail
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
    charset=windows-1252

If you receive a pgp encrypted mail from Apple users it will not only have a obscure char set encoding it will also be encoded as quoted-printable before the encryption with gpg. This results in a lot of pain for e.g. German mails. Not only newlines (=20) will look great also the umlauts ä (=E4) ü (=FC) and so on will be terrible for reading after decryption.

The first step to get rid of this is to convert the quoted printable stuff into a more human friendly format - luckily Perl can do this for us. Afterwards it is nice to convert the resulting string into UTF-8 - e.g. with iconv. This all can be assembled into a pretty simple shell script:

#!/bin/bash

# Convert Apple Mail gpg into nice format.

gpg --decrypt $1 | perl -pe 'use MIME::QuotedPrint; $_=MIME::QuotedPrint::decode($_);' | iconv -f WINDOWS-1252 -t UTF-8 >> $1

Great! You just throw the file with the PGP blob into the script and it appends it in a human readable text - even if it came from Apple Mail...

Often programming is seen as the stupid necessarily at the end of the interesting parts of application development. A job that can be done by some code monkey - since everybody can program...

In my daily job as application developer I found some examples that may result by those opinions (sorry for the COBOL source...):

           EVALUATE TRUE
             WHEN IN-DATE-TYPE-CODE = '2'
               MOVE IN-DATE-TYPE-CODE       TO OUT-DATE-TYPE-CODE
               MOVE IN-START-DATE           TO OUT-START-DATE
               MOVE IN-END-DATE             TO OUT-END-DATE
             WHEN OTHER
               MOVE '2'                     TO OUT-DATE-TYPE-CODE
               MOVE IN-START-DATE           TO OUT-START-DATE
               MOVE IN-END-DATE             TO OUT-END-DATE
           END-EVALUATE

The sample above made me curious so I really tried to understand the intention of the creator. Was this tautology thought to be more readable? Was there another option in a previous version of the code (due to the version history: NO)? Did he know what he was doing?

Finally I gave up and committed a version that just fills the OUT-DATE-TYPE-CODE with '2' every time... nothing but the maintainability changed.

A slightly more complex example is shown below (note: LOW-VALUE means HEX 00 in COBOL and alphanumeric fields can be compared by their HEX VALUE ('A' > SPACE)):

           IF FIELD-A = LOW-VALUE OR SPACE
              MOVE LOW-VALUE                    TO OUT-FIELD
           ELSE
              MOVE FIELD-A                      TO OUT-FIELD
           END-IF

           IF OUT-FIELD = LOW-VALUE
              IF FIELD-B = SPACE OR LOW-VALUE
                 MOVE LOW-VALUE                 TO OUT-FIELD
              ELSE
                 MOVE FIELD-B                   TO OUT-FIELD
              END-IF
           END-IF

This code is quiet hard to read (even after I removed a lot of noise that was in the actual program...). As a first step the common initialization values (LOW-VALUE and SPACE) of FIELD-A are checked (so control characters as HEX 01 - 39 (EBCDIC) are seen as valid - which is a severe error in this context). If the value is invalid the target field gets initialized. Later in the code this initialization is checked again and afterwards another field may be moved into the target OUT-FIELD.

All this confusing code may be reduced to:

           EVALUATE TRUE
              WHEN FIELD-A > SPACE
                 MOVE FIELD-A                   TO OUT-FIELD
              WHEN FIELD-B   > SPACE
                 MOVE FIELD-B                   TO OUT-FIELD
              WHEN OTHER
                 MOVE LOW-VALUE                 TO OUT-FIELD
           END-EVALUATE

Again the code does the same as before (it is just more secure against errors due to control characters) BUT it can be read and understand way easier.

The two anecdotal examples above are just to illustrate the point that good source code is more than 'something that does it' it is also important to illustrate what the code should do- a future developer (or even future you) will thank you.

Jenkins on Synology Disk Station

This little guide shows you how to set up a Jenkins server on your Synology Disk Station. It is assumed, that you already connected to your Disk Station via SSH and have a favorite text editor.

• Create User jenkins Watch out: 145 is just a unused ID - may has to be changed

• /etc/password:

  jenkins:x:145:145:Jenkins:/var/lib/jenkins:/bin/sh

• /etc/shadow:

  jenkins:*:10933:0:99999:7:::

• /etc/group:

  jenkins:x:145:jenkins

• Create Jenkins directory / home

  mkdir /opt/jenkins/ 

• Optional: Symlink in /var

  ln -s /opt/jenkins /var/lib/jenkins/

• Allow Jenkins to modify its home

  cd /opt
  chown jenkins:jenkins jenkins

• Download latest Jenkins

  cd /opt/jenkins
  wget http://mirrors.jenkins-ci.org/war/latest/jenkins.war

• Copy jenkins.sh to /usr/local/etc/rc.d/ don't forget chmod +x
• Link into autostart (this step does not work propper - you might have to start the jenkins manually after every boot).

  ln -s /usr/local/etc/rc.d/jenkins.sh /usr/syno/etc/rc.d/S999jenkins.sh

Your Jenkins server is now up and running on the port 8080 of your NAS. Have fun.