After months of planning the first (hopefully) annual GCC Developer's Summit will be happening in Ottawa, Canada from May 25th-27th, 2003. The event is for both those interested in and working on compiler internals (GCC, G++, GJC, etc), associated tools such as Binutils, and for those developers who use these tools in their daily work.
The official web site is up at http://www.gccsummit.org/ and more information is going up daily.
We believe that the compiler technology coming out of the GNU GCC (GNU Compiler Collection) is some of the most important work in Free Software and that bringing together everyone once a year will help increase interest and introduce new people into the GCC fold.
We would very much appreciate it if the Advogato community could help us reach relevant people and ensure they know that the Summit is happening.
Please feel free to contact me directly at firstname.lastname@example.org with any questions or suggestions, feedback is key to ending up with a great event.
I saw an interesting presentation at CodeCon recently. It was for Hydan, a steganographic system that hid things inside of executables. It did this by subtly altering which instructions were used when there were several equilength instructions that could be used to accomplish a given thing.
One problem it had was that it altered the statistic of the instructions used because compilers tend to make very predictable choices as to which instruction to use in any given case. I thought it might be interesting for gcc to randomly decide which instruction to use, but only if there were no other reasons (like speed) to choose one instruction over the other. This would make steganographic systems like Hydan much more useful.
Of course, this does cause .o files and executables to no longer be deterministic. And that could be bad for any number of reasons. But it would do a lot to help people communicate in situations where their government was actively trying to prevent them from doing so.
It actually has some significant disadvantages over image steganography. The encoding rate is much lower, for example.
The problem in steganography is successfully hiding the fact that your overt message contains a covert message. In order for this to be successful, the statistical properties of a message that contains a covert message have to not be detectably different from the statistical properties of a message that contains no covert message. This is very difficult to achieve.
It might be much easier if various encoders of overt messages (like compilers) had some common way of adding random harmless noise to their messages.
It could simply be an option that provided a random seed to a cryptographically secure random number generator like Yarrow. The seed would default to always being some certain value, but there could also be a switch that pulled the seed from /dev/random, or from the command line. The default version of rpmbuild, or other tools that packaged up executables could then use this flag by default. For them, the ability to exactly reproduce a binary isn't so important. That ability is only REALLY important when debugging the compiler or doing builds during development and testing.
This presupposes that the ability to covertly send a message is of such vital importance that people should seriously consider specifically accomodating steganographers. Knowing that PGPs original purpose was to help people report human rights abuses to amnesty international tends to make me pretty sympathetic to people who want to send messages without their government knowing about them or being able to read them.