Posts on tag: source

On FreeBSD (and possibly others) the csh is the default login shell for root or default users. I always try to avoid it and use bash. However, sometimes it's not possible or dangerous to install bash (inside a jail for example).

So I decided to check if it is possible to configure csh in a way to make it less annoying. I read the docs, tried many different options and here is the result.

That's not much but helps digging around a system using csh. With this config you'll get:

• completion similar to bash
• right/lift jumping by words using CTRL-left and CTRL-right
• CTRL-up goto beginning of line, CTRL-down goto end of line
• history search using CTRL-R
• some sensible aliases
• a meaningful prompt

# sensible defaults for CSH 
alias  h     history 25
alias  j     jobs -l
alias  la    ls -a
alias  lf    ls -FA
alias  ll    ls -lA
alias  l     ls -laF
alias  lt    ls -ltr
alias  md    mkdir -p
alias  ..    cd ..
alias  ...   cd ../..
alias  ....  cd ../../../
alias  vi    nvi
alias  vim   nvi
# A righteous umask
umask 22
# environment config
set path = (/sbin /bin /usr/sbin /usr/bin /usr/local/sbin /usr/local/bin $HOME/bin)
setenv  EDITOR      vi
setenv  PAGER       more
setenv  BLOCKSIZE   K
# if interactive, configure further
if ($?prompt) then
# interactive prompt
  set prompt = "%N@%m:%~ %# “
set promptchars = ”%#"
# history config
  set history = 5000
set savehist = 5000
# complete case-insensitive
  set complete = enhanced
# print possible completions if more than 1 match
  set autolist = ambiguous
# enable filename completion
  set filec
# shut up
  set nobeep
# enable redirect protections
  set noclobber
# forbid rm *
  set rmstar
# mail?
  set mail = (/var/mail/$USER)
# convenience bindkeys, similar to emacs or inputrc
  # ALT-LEFT
  bindkey "^[^[[D" backward-word
# ALT-RIGHT
  bindkey "^[^[[C" forward-word
# ALT-UP + HOME
  bindkey "^[^[[A" beginning-of-line
# ALT-DOWN + POS1
  bindkey "^[^[[B" end-of-line
# CTRL-R (like bash), then type
  bindkey "^R" i-search-back
# SHIFT-TAB cycles through possible completions, let go if good
  bindkey "^[[Z" complete-word-fwd
endif

While working on a project with Moo (the first time for me) I discovered Try::Tiny. It's a great little helper and I highly recommend it. However, on my quest to make better error handling in Perl I thought it would be a good idea to have some kind of exception system.

Turns out, this already exists. In fact it is quite simple: die() accepts a reference as parameter, which could very well be an object. A couple of modules on CPAN make use of this, one of the simplest with the fewest dependencies is Throwable.

Since I could not find a good example of how to use it correctly (which I understood), I'm going to post such an example here for anyone who might be interested.

So, you need to have Moo and Throwable installed first. I'm doing these kind of experiments with perbrew, which I recommend as well! Here's my "Exception" class. It's a Moo role with two attributes (type and msg) and a class method e().

package Ex;
use Moo;
with 'Throwable';
has type => (is=>‘ro’);
has msg  => (is=>‘ro’);
sub e {
if (ref($) eq ‘Ex’) {
return $;
} else {
chomp; return Ex->new(msg => $_, type=>0);
}
}

This Exception class will act as our wrapper to throw exceptions or convert old school perl die()'s into exceptions.

Here is a simple Moo class without any attributes which implements two methods X::Nix::tu() and X::Nix::ta(). Both of them just die. The method tu() throws an exception of type Ex - our exception class from above comes into use here. The ta() method on the other hand just dies with a good old croak() call.

package X::Nix;
use Carp;
use Ex;

use Moo;
sub tu {
Ex->throw({type => 1, msg => ‘dont die while root’});
}
sub ta {
croak “death by disruptor”;
}

Now let's take a look at our main script, which uses the X::Nix class and tries to catch both exceptions:

package main;
use Try::Tiny;
use X::Nix;
my $x = X::Nix->new();
try {
$x->tu;
} catch {
printf “died with %d and said: <%s>\n”,
Ex::e->type, Ex::e->msg;
};
try {
$x->ta;
} catch {
printf “died with %d and said: <%s>\n”,
Ex::e->type, Ex::e->msg;
};

It calls both methods and tries to catch them. Note how it calls Ex::e->type, though: Try::Tiny puts the exception object/message into $_. The class method Ex::e() uses $_ directly, therefore we are able to leave it in our catch{} code. This is the same thing as Ex::e($_)->type. Here's the output:

died with 1 and said: <dont die while root>
died with 0 and said: <death by disruptor at role.pl line 49.>

So, as you can see, with the help of our Ex::e() class method we can handle real exceptions and old school die()'s the same way, wo don't need to distinguish between the two. This way you can use foreign perl modules which use croak() and die() and catch those errors as if they were exceptions.

So, the german and french government want to break cryptography. Now they "only" want to be able to decrypt messaging apps. If they get their law - and since there's not much sanity left in the corrupt EU this will likely happen - what will be next?

I think store and forward crypto systems are the first to come into mind, that is: PGP. Happily I am the maintainer of some nice but working play store and forward crypto software: PCP. Of course it is not PGP but uses comparable features. So, after reading the news the other day I thought to myself:

How would I implement such a backdoor in PCP, if I had to?

As it turned out the answer is hillariously simple! PCP, as GNUPG, supports encrypting data for multiple recipients. Therefore the task is easy: create a "government key pair", hardcode its public key into the encryption code and encrypt everything for this recipient as well.

Here's the backdoor patch.

The patch includes the "government's" secret key. Here's how to use it:

1. Compile the patched pcp source as usual, install the binary as pcp1-backdoored or something like that.
2. Create a test user on your system, say "spook".
3. As user "spook" import said secret key, the import passphrase is "gov".
4. As another user on the same system export your public key.
5. Import that key as user "spook".
6. Now as the regular user, encrypt some file asymmetrically for someone else (e.g. import one of the public key files in the tests/ directory of the source code) using the backdoored binary.
7. As user "spook" decrypt the encrypted file as if you'd be the intended recipient.
8. Et voilá.

Demo:

[24.Aug 17:09:05] --- [~] ---
tom@vm: % src/pcp1 -V spiedsender.vault -l
Key ID               Type             Creation Time        Owner
0x5C77C305F0BF8333   primary secret   2016-08-24T15:13:02  Freddy Victim <victim@gmail.foo>
0x616BDDA58845987B   valid public     2015-04-17T17:08:19  Bobby <bobby@local>
[24.Aug 17:15:29] — [~] —
tom@vm: % src/pcp1 -V backdoor.vault -l
Key ID               Type             Creation Time        Owner
0xF93E7016447D28CC   primary secret   2016-08-24T14:54:28  The Government <spooks@the.gov>
0x5C77C305F0BF8333   valid public     2016-08-24T15:13:02  Freddy Victim <victim@gmail.foo>
[24.Aug 17:15:43] — [~] —
tom@vm: % echo “for bobbys eyes only” | src/pcp1 -V spiedsender.vault -i 0x616BDDA58845987B -e -O encrypted-for-bobby.asc
Enter passphrase to decrypt your secret key:
Encrypted 242 bytes for:
0x616BDDA58845987B - Bobby <bobby@local>
[24.Aug 17:16:14] — [~] —
tom@vm: % src/pcp1 -V backdoor.vault -I encrypted-for-bobby.asc -d
Enter passphrase to decrypt your secret key:
for bobbys eyes only
Decrypted 21 bytes successfully

There you go. Freddy Victim encrypted some message for Bobby, but the "government" could read it anyway, it only had to import Bobby's public key (which is the difference to PGP, but it's public and much easier to retrieve).

Also note that the "government" just uses regular PCP features, it doesn't even need to use a patched binary, the vanilla one would do. That's because the backdoor is not really a cryptographic backdoor (which is, as many cryptographers already said, impossible). Instead it just adds another recipient. The result looks pretty normal to the uninitiated, just some encrypted file decryptable by two recipients instead only one.

So, as you can see, it couldn't be easier to implement this backdoor. I could even commit this code to Github and I'm pretty sure, no one would take notice (and of course in that case I'd obfuscate it a little to disguise a casual reader). Also, the government could distribute the patched binary. That'd be pretty easy as well, since almost all Open Source systems use binary packaging.

Finally, one question remains though:

How could I determine of an encrypted file has a "hidden" recipient?

I'm not sure. In the case of PCP, I added a debug print statement to the decryption code (git commit) which tells the number of recipients during decryption if -v have been supplied on the command line. Maybe GPG already includes such a function. But of course this could be easily patched away by a backdoored version. So to check if an encrypted file contains more recipients than expected you'd need to check out the source code, compile it manually and then do the checks.

Yes, evil and scary stuff. But as the README of PCP says loud and clearly: Do not use PCP for anything productive or important. However, for real live public key crypto systems the scheme to add a government recipient to all encrypted data could be a realistic possiblity.

 

This is a response to the article "Maintainers Matter" by Kyle Keen, which I'm posting here, since his comment system doesn't work for me.

First of all: I agree with you that maintainers are indeed required and do matter - for users of linux distributions. But I think your world view is a little bit too focused on linux distributions:

Supposedly one of Linux's failings is that there is too much pointless choice, too many K and G versions of things and it divides developer efforts. Why have so many window managers and text editors?

This is no failing, this is good. Who is to decide which WM I'm going to use? A maintainer? You? Why? What could I do if my distribution only provides Gnome but I'm a non-mouse-user and NEED xmonad?

Linux is about choice and it's the choice of the users, not the maintainers. That's why we do have so many different distributions: because at some point maintainers went mad, excluded users with their decisions, so the users had to make a fork of the distribution.

Somehow we've gotten this idea that everyone who writes software for Linux does it for the warm fuzzies.

I am writing software. Free software. NOT software for Linux. In fact, I don't care about Linux at all. My software is free, I provide the source, it runs on most unices, including Linux. And besides it is none of your business, what I'm doing it for. Be it for the lulz, for the "warm fuzzies" or for money - as long as the software comes with a free license which enables users to use it as they wish, it is free and everything is good.

Oh, and from my point of view there's only the developer (that would be me) and users. As you see, users includes maintainers. There's no difference. I do not handle bug reports differently whether they come from an "end user" or some "ubuntu maintainer". And why should I?

More fundamentally, the maintainer is the primary line of defence and interaction between users and developers. Maintainers shield developers from uninformed users, allowing the devs to write software with less support overhead. Non-bugs are caught and filtered out. Low-quality bugs reported to the distribution's tracker often becomes a good bug when the maintainer reports it upstream.

Maintainers may do whatever they want, I don't care. But they're not a "line of defence" or some shield between me and users. Maintainers are, if any, a proxy or a filter. I don't need a "line of defense" since I don't consider users to be my enemies. And even if I would, then maintainers would be enemies as well. So where's the point?

And what is a "non-bug"? Who decides? What if I want to know about it? What if it is not a bug, but just feedback. Why in the world is this hidden from me?

Without distros the ISV would have to carry the full weight of support.

Oh, look at the young one :) Do you know, there was a time when no "distributions" were around? During that time, developing and supporting free software was no burden nevertheless.

This is why Linux doesn't have spyware, doesn't come with browser toolbars, doesn't bundle limited trials, doesn't nag you to purchase and doesn't pummel you with advertising.

Wrong. It doesn't have spyware because it's not widespread. Oh, my bad, that's wrong too. Of course there's LOTS of spyware for Linux. Every android device has it installed. Ubuntu contains spyware. Sanctioned by a "maintainer" of some kind.

For the sake of argument, let us presume that all ISVs are ethical and hold the interests of the community as their utmost ideal.

Again, that's not the point of free software. I produce free software so you can do with it whatever you want, including modifying or distributing it. I'm not interested in your ethical values, your religion, your gender, your education, your location or even your species.

And it's the same the other way around: none of those things about me is your business.

But there's another major misconception here: "the community" you say. Which one? The community of Arch Linux users? Linux Users? Unix Users? Free Software Users? Software Users? Users? In the reality (to reuse you phrasing) there's no such thing as "the community". There are a bunch of people who use Arch Linux, but this doesn't constitute automatically a community. Most of Arch Linux users are unknown to Arch Linux maintainers. They are NOT part of whatever kind of community you're dreaming of. And this is the case for all kinds of users.

As long as people just use something, whether they pay for it or not, they are just users of this thing. Take Zippo users for example. Even if there's some "Zippo Community" somewhere, I am not part of that community only because I use a Zippo lighter!

I am part of a community if I subscribe to some list, apply for a forum account, post comments or opinions, contribute code, documentation or the like. Everyone else is not part of this. Seeing it this way is communist thinking. Free people decide themselfes if they want to be part of some kind of "movement" - not some maintainer somewhere in the U.S.

Could ISVs possibly make everyone happy? They can't. It is impossible.

As maintainers can't do as well. That's why we have thousands Linux distros, a couple of BSD's, hundreds of editors, hundreds of window managers and possibly billions of different ways to combine and configure them. And that's the idea behind the whole endeavor, isn't it?

So, let them make universal packages. Who cares? I'll continue to manually compile emacs and xmonad myself whatever distro I'm running on.

Haha, Fefe musste sich mit RPM beschäftigen und war not amused:

Oh und wer hat sich denn bitte das RPM-Dateiformat ausgedacht?! Was soll das werden? Soll das außerirdische Invasoren in den Wahnsinn treiben, damit sie nicht die Menschheit ausrotten können? Heilige Scheiße. Dagegen ist ja der Debian-Kram einleuchtend und selbsterklärend! Und selbstdokumentierend gar. Wie ein .deb funktioniert, kann man mit file und Hausmitteln rausfinden, man braucht nicht mal einen Hex-Editor.

LOL. Ich finde das Debianformat ja schon fürchterlich. Aber RPM schlägt dem Fass in der Tat den Boden aus.

Gott sei Dank muss ich mich mit solch einer Scheisse nicht beschäftigen, FreeBSD sei Dank!