Fwd: Building gcc-4.9 on OpenBSD
The reason I'm doing this is that I want to understand why the total size of the binaries grew from around 10MB (gcc v 4.5) to over 70MB in 4.9 I can compile the first stage OK, and the binaries are quite modest: -rwxr-xr-x 1 ian ian 17.2M Sep 6 03:47 prev-gcc/cc1 -rwxr-xr-x 1 ian ian 1.2M Sep 6 04:24 prev-gcc/cpp -rwxr-xr-x 1 ian ian 1.2M Sep 6 04:24 prev-gcc/xgcc The 2nd stage doesn't compile however, because the Intel library doesn't support OpenBSD. The host/target is i386-unknown-openbsd5.4: ../.././libcilkrts/runtime/os-unix.c:69:5: error: #error "Unsupported OS" # error "Unsupported OS" ^ ../.././libcilkrts/runtime/os-unix.c: In function '__cilkrts_hardware_cpu_count': ../.././libcilkrts/runtime/os-unix.c:386:2: error: #error "Unknown architecture" #error "Unknown architecture" ^ Makefile:691: recipe for target 'os-unix.lo' failed My questions are, is this what I should expect in terms of file sizes?: ian3@jaguar:~/build/guile-2.0.11$ ls -l ~/usr/bin/gcc ~/usr/libexec/gcc/i686-pc-linux-gnu/4.9.0/cc1 -rwxr-xr-x 3 ian3 ian3 2538426 2014-08-03 01:18 /home/ian3/usr/bin/gcc -rwxr-xr-x 1 ian3 ian3 66149541 2014-08-03 01:18 /home/ian3/usr/libexec/gcc/i686-pc-linux-gnu/4.9.0/cc1 ian3@jaguar:~/build/guile-2.0.11$ And is there any way to disable the Intel library? The fact that the first stage bootstrap works without it indicates that it might be possible. Thanks Ian
Fwd: Building gcc-4.9 on OpenBSD
The reason I'm doing this is that I want to understand why the total size of the binaries grew from around 10MB (gcc v 4.5) to over 70MB in 4.9 I can compile the first stage OK, and the binaries are quite modest: -rwxr-xr-x 1 ian ian 17.2M Sep 6 03:47 prev-gcc/cc1 -rwxr-xr-x 1 ian ian 1.2M Sep 6 04:24 prev-gcc/cpp -rwxr-xr-x 1 ian ian 1.2M Sep 6 04:24 prev-gcc/xgcc The 2nd stage doesn't compile however, because the Intel library doesn't support OpenBSD. The host/target is i386-unknown-openbsd5.4: ../.././libcilkrts/runtime/os-unix.c:69:5: error: #error "Unsupported OS" # error "Unsupported OS" ^ ../.././libcilkrts/runtime/os-unix.c: In function '__cilkrts_hardware_cpu_count': ../.././libcilkrts/runtime/os-unix.c:386:2: error: #error "Unknown architecture" #error "Unknown architecture" ^ Makefile:691: recipe for target 'os-unix.lo' failed My questions are, is this what I should expect in terms of file sizes?: ian3@jaguar:~/build/guile-2.0.11$ ls -l ~/usr/bin/gcc ~/usr/libexec/gcc/i686-pc-linux-gnu/4.9.0/cc1 -rwxr-xr-x 3 ian3 ian3 2538426 2014-08-03 01:18 /home/ian3/usr/bin/gcc -rwxr-xr-x 1 ian3 ian3 66149541 2014-08-03 01:18 /home/ian3/usr/libexec/gcc/i686-pc-linux-gnu/4.9.0/cc1 ian3@jaguar:~/build/guile-2.0.11$ And is there any way to disable the Intel library? The fact that the first stage bootstrap works without it indicates that it might be possible. Thanks Ian
Re: Fwd: Building gcc-4.9 on OpenBSD
On Wed, Sep 17, 2014 at 1:36 PM, Marc Glisse wrote: > On Wed, 17 Sep 2014, Ian Grant wrote: > >> And is there any way to disable the Intel library? > --disable-libcilkrts (same as the other libs) > If it explicitly doesn't support your system, I am a bit surprised it isn't > disabled automatically, that seems like a bug. Not necessarily a bug, but it would have been good if the --help option had mentioned it. I looked, really. Perhaps I missed it though. So many options for disabling one thing or another > Please don't call it "the Intel library", that doesn't mean anything. Doesn't it? How did you know what 'it' was then? Or is that a stupid question? This identity concept is much slipperier than it seems at first, isn't it? How about my question about the size of the binaries? Is that 60+MB what other systems show? What is the extra function 4.9 has over 4.5 to which I'm dedicating 50MB of disk? Warning messages? Ian
Re: Fwd: Building gcc-4.9 on OpenBSD
On Wed, Sep 17, 2014 at 2:59 PM, Marc Glisse wrote: >>> Please don't call it "the Intel library", that doesn't mean anything. >> Doesn't it? How did you know what 'it' was then? Or is that a stupid >> question? This identity concept is much slipperier than it seems at >> first, isn't it? > You included error messages... Context. And this is what gave that noun meaning. Context is important in semantics. You can't tell what anything, a C compiler binary, for example, means in isolation. >> How about my question about the size of the binaries? Is that 60+MB >> what other systems show? > > I still see <20M here, but I don't know if there are reasons for what you > are seeing. Are you maybe using different options? (debug information, > optimization, lto, etc) That is very useful to know. Thanks. Ian
Re: Fwd: Building gcc-4.9 on OpenBSD
On Thu, Sep 18, 2014 at 5:37 PM, Ian Grant wrote: > > On Thu, Sep 18, 2014 at 5:22 PM, Tobias Ulmer wrote: >> >> On Wed, Sep 17, 2014 at 01:26:48PM -0400, Ian Grant wrote: >> > The reason I'm doing this is that I want to understand why the total >> > size of the binaries grew from around 10MB (gcc v 4.5) to over 70MB in >> > 4.9 >> >> There is indeed a problem with huge binaries on OpenBSD/arm, which I've >> not yet figured out, but i386/amd64/sparc64 are fine. > > > I don't have huge binaries (c.f. "Buster Gonad and his Infeasibly Large > Testicles") on Open BSD. I have them on i686-pc-linux-gnu. > > -rwxr-xr-x 1 ian3 ian3 64M 2014-08-03 01:18 cc1 > -rwxr-xr-x 1 ian3 ian3 65M 2014-08-03 01:18 cc1obj > -rwxr-xr-x 1 ian3 ian3 68M 2014-08-03 01:18 cc1plus > -rwxr-xr-x 1 ian3 ian3 1.8M 2014-08-03 01:18 collect2 > -rwxr-xr-x 1 ian3 ian3 65M 2014-08-03 01:18 f951 > >> Are you trying to build gcc from the vanilla sources? If so, you're in >> for a treat... > > > I didn't know there was chocolate source! Where is it?! And why is it a > secret? > > Ian >
Re: Fwd: Building gcc-4.9 on OpenBSD
On Thu, Sep 18, 2014 at 5:22 PM, Tobias Ulmer wrote: > On Wed, Sep 17, 2014 at 01:26:48PM -0400, Ian Grant wrote: >> I can compile the first stage OK, and the binaries are quite modest: >> >> -rwxr-xr-x 1 ian ian 17.2M Sep 6 03:47 prev-gcc/cc1 >> -rwxr-xr-x 1 ian ian 1.2M Sep 6 04:24 prev-gcc/cpp >> -rwxr-xr-x 1 ian ian 1.2M Sep 6 04:24 prev-gcc/xgcc > > Gcc 4.9 binaries on OpenBSD/amd64 are resonable: > > -r-xr-xr-x 1 root bin11.6M Sep 9 03:02 cc1 > -r-xr-xr-x 1 root bin15.4M Sep 9 03:02 gnat1 > -r-xr-xr-x 1 root bin 749K Sep 9 03:02 ecpp I think we need to be able to explain this. It's an increase of over 60%, I wouldn't expect that to be due to the relative ineffiiciency of Intel instruction encoding over AMD. And it is not due to the inclusion of libsylkrts (it's much easier to say "Intel library", how many other libraries are there in GCC that were written by Intel?) because that is not in the stage1 bootstrap. Ian
Re: Fwd: Building gcc-4.9 on OpenBSD
On Thu, Sep 18, 2014 at 6:54 PM, Jonathan Wakely wrote: > On 18 September 2014 23:46, Ian Grant wrote: >> On Thu, Sep 18, 2014 at 5:22 PM, Tobias Ulmer wrote: >>> On Wed, Sep 17, 2014 at 01:26:48PM -0400, Ian Grant wrote: >>>> I can compile the first stage OK, and the binaries are quite modest: >>>> >>>> -rwxr-xr-x 1 ian ian 17.2M Sep 6 03:47 prev-gcc/cc1 >>>> -rwxr-xr-x 1 ian ian 1.2M Sep 6 04:24 prev-gcc/cpp >>>> -rwxr-xr-x 1 ian ian 1.2M Sep 6 04:24 prev-gcc/xgcc >>> >>> Gcc 4.9 binaries on OpenBSD/amd64 are resonable: >>> >>> -r-xr-xr-x 1 root bin11.6M Sep 9 03:02 cc1 >>> -r-xr-xr-x 1 root bin15.4M Sep 9 03:02 gnat1 >>> -r-xr-xr-x 1 root bin 749K Sep 9 03:02 ecpp >> >> I think we need to be able to explain this. It's an increase of over >> 60%, I wouldn't expect that to be due to the relative ineffiiciency of >> Intel instruction encoding over AMD. And it is not due to the >> inclusion of libsylkrts (it's much easier to say "Intel library", how >> many other libraries are there in GCC that were written by Intel?) > > liboffload might get added soon. I don't know what that is. I'll look it up later maybe. >> because that is not in the stage1 bootstrap. > > Are you looking at stripped binaries or unstripped? I don't know. How should I find out, read the Makefile? :-) Doesn't the stage-1 get stripped? I'm not a GCC developer, I'm a 'user.' > Have you compared the binaries using size(1) instead of ls(1)? Yes, they're a lot smaller. Are you suggesting the filesystem size is just holes in the file? I would want to know what data is in there. Think of this as a security audit. Ian
Re: Fwd: Building gcc-4.9 on OpenBSD
On Thu, Sep 18, 2014 at 6:54 PM, Jonathan Wakely wrote:
> On 18 September 2014 23:46, Ian Grant wrote:
>> On Thu, Sep 18, 2014 at 5:22 PM, Tobias Ulmer wrote:
> Have you compared the binaries using size(1) instead of ls(1)?
Actually, when I look at the output of size I realise I don't know
what it means:
ian3@jaguar:~/usr/libexec/gcc$ size i686-pc-linux-gnu/4.9.0/{cc1,f951}
text databssdechexfilename
14965183 23708 74494415733835 f0144b
i686-pc-linux-gnu/4.9.0/cc1
15882830 29264 75083216662926 fe418e
i686-pc-linux-gnu/4.9.0/f951
The phrase "dangerous GNU crap" comes to mind :-)
Ian
Re: Fwd: Building gcc-4.9 on OpenBSD
On Thu, Sep 18, 2014 at 8:32 PM, Jonathan Wakely wrote:
>> ian3@jaguar:~/usr/libexec/gcc$ size i686-pc-linux-gnu/4.9.0/{cc1,f951}
>>text databssdechexfilename
>> 14965183 23708 74494415733835 f0144b
>> i686-pc-linux-gnu/4.9.0/cc1
>> 15882830 29264 75083216662926 fe418e
>> i686-pc-linux-gnu/4.9.0/f951
>>
>> The phrase "dangerous GNU crap" comes to mind :-)
> If you say so. The size command is older than GNU, or BSD for that matter.
It's OK. A GNU can't be blamed for crapping, it's natural :-).
> Your OS probably has a man page for it.
It does. "Copyright (c) 1991-2013 Free Software Foundation, Inc."
But the man page doesn't tell me what the column headings actually
mean. And even if it did, why should I have to look up the manual to
find out what the headings mean? What's the point of headings? Since
they aren't even aligned, it might just as well leave the out
altogether: they're just a waste of screen space.
But I don't want to argue about GNU crap, it's a natural and
understandable phenomenon, and not particularly interesting. I want to
know what's in the GCC binaries. So let's focus on that.
What was the reason you suggested I look at the output of the size
command? What does that tell me about what is the cause of the holes
in the file, or the extra padding, or whatever it is you think is the
explanation for this phenomenon?
Ian
Re: Fwd: Building gcc-4.9 on OpenBSD
In case it isn't obvious, what I am interested in is how easily we can know the problem of infeasibly large binaries isn't an instance of this one: http://livelogic.blogspot.com/2014/08/beware-insiduous-penetrator-my-son.html Ian
Re: Fwd: Building gcc-4.9 on OpenBSD
On Thu, Sep 18, 2014 at 9:37 PM, Joe Buck wrote: > (delurking) > Ah, this is commonly called the Thompson hack, since Ken Thompson > actually produced a successful demo: How do you know Thompson's attempt was the first instance? The document I refer to in the blog is the "Unknown Air Force Report" Thompson refers to. It was written by Roger Schell (cc'ed) > http://www.win.tue.nl/~aeb/linux/hh/thompson/trust.html > The only way that the Thompson hack can survive a three-stage > bootstrap is if the compiler used for the stage 1 build has the bad > code. This is the overwhelmingly likely (probability 1) case. How else would the stage-2 and three compilers get the bad code? > The comparison between stages 2 and 3 require exact match, > and any imperfection in the object code injection would reveal itself. How? In the output of a utility, or a system device driver, on a system booted from a boot loader and using standard libraries such libc, all compiled by the same bug in the compilers which compiled the stage 1, 2 and 3 C compilers? > So, you can build GCC with LLVM or Intel's compiler or Microsoft's or IBM's > or Sun's, doing cross-compilation where necessary. Do these compilers all support cross-OS compilation to any OS? It sounds a bit hard to me. I just can't imagine MS, say, going to a great deal of trouble to make sure that their compiler targets Linux and OpenBSD. GCC needs quite a lot of library and OS support, doesn't it? People will have to help me a bit with this, I've not yet managed to cross-compile anything. This thread started because I was just trying to build gcc from Vanilla gcc-4.9 sources on OpenBSD, and it doesn't work. See the earlier messages. I was next going to try to build gcc-4.9 on OpenBSD, cross-targetting Linux on the same physical machine (i.e. same CPU) but I don't imagine this will be at all easy, given I can't even build the vanilla sources. People say there is chocolate source, but no-one has told me where it is yet! > The basic idea is: > > 1: build gcc with 3-stage bootstrap, starting with a compiler that you > suspect might be infected. call the result A. > 2: do it again, starting with a different compiler that you think is > independent of the compiler you used in step 1. call it B. > 3: compare A to B. If they differ, you've found something that should > be investigated. If you don't, then either A and B are both clean, or A > and B both have the identical inserted object code. Maybe they have > common ancestor? > > Note that if you build gcc with a cross-compiler the object code will be > different. > You have to use the cross-compiler to build one more time to "normalize": > GCC 4.9.0 built with GCC 4.9.0 on operating system X should always be > the same. Yes, but the problem is when the object code bug is not in the compiler binaries, it's something injected into the compiler binaries from the infected ld.so, or glibc, or the IDE disk device driver, and it infects the source to those programs. > As far as I know no one has been paranoid enough to put in the time to do > the experiment on a large scale, and it's harder because you can't build > a modern GCC (or LLVM for that matter) with an ancient compiler. But > you can create a chain: grab an ancient gcc version off a 15-year-old CD, When did you last try grabbing an ancient gcc off a 15 year old CD and getting to run on a modern OS? Was it easy? > and build newer versions with it until you get up to the present. And the rest of the chain, are they easier still? > The result should be byte-for-byte identical with what you get when > building the current compiler with a recent version. And what does that tell me, really? > If it is, then either the infection is 15 years old or does not exist. How do you figure that? > Try it again by building cross-compilers from a Microsoft system. > Don't trust Apple, they used to use GCC so maybe all their LLVM > binaries caught the bug. Interesting idea. > BTW, if "size" is reporting much smaller size than the executable > file itself and that motivates this concern, most of the difference > is likely to be debug info, which is bigger since gcc switched to > C++. Might want to try "strip". Great. As I said, the exercise we are here engaged in is to convince as many people as possible that GCC does NOT suffer from this problem on any OS, either OS, Windows, OpenBSD, FreeBSD, Solaris, or Linux on any arch., including IBM System z. So can someone tell me the quickest way to build a new set of binaries, stripped, or just how to tell whether the stage-1 binaries are in fact stripped or not? And can anyone tell me what are the 'non-vanilla' sources? Ian
Re: Fwd: Building gcc-4.9 on OpenBSD
On Thu, Sep 18, 2014 at 10:35 PM, Thomas Preud'homme wrote: >> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of >> Ian Grant >> >> And can anyone tell me what are the 'non-vanilla' sources? > > "Vanilla source" refers to unmodified source (as distributed on gcc.gnu.org > for the case of gcc). This is in contrast to modified source from distribution > for instance that will usually add some patches. Hi Thomas, Thanks. But I asked what the non-vanilla sources were. I know what the vanilla sources are, because I'm using them! I thought you were referring to some particular OpenBSD patches that would make it easier for me to do this. I'm not aware of any: the OpenBSD people have a v. 4.2.1 GCC fork that they use, but it is 4.9 I am interested in building on OpenBSD, to get a 'cross reference' which I hope might tell me something about the file sizes I see, Thanks, Ian > Best regards, > > Thomas > > > >
Dijkstra's Methodology for Secure Systems Development
t generally understood of acknowledged, but my vision of the more detailed structure of that vision was still vague. Halfway [through] the multiprogramming project in Eindhoven I realized that we would have been in grave difficulties had we not seen in time the possibility of definitely unintended deadlocks. From that experience we concluded that a successful systems designer should recognize as early as possible situations in which some theory was needed. In our case we needed enough theory about deadlocks and their prevention to develop what became known as "the banker's algorithm", without which the multiprogramming system would only have been possible in a very crude form. By the end of the period I knew that the design of sophisticated digital systems was the perfect field of activity for the Mathematical Engineer." [1] Edsger W. Dijkstra. EWD1303 https://www.cs.utexas.edu/users/EWD/transcriptions/EWD13xx/EWD1303.html [2] Luis Damas and Robin Milner, Principal Type-schemes for Functional Programs, In: Proceedings of the 9th ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages ACM, 1982, 202--212. http://prooftoys.org/ian-grant/hm/milner-damas.pdf [3] John Harrison, Introduction to Functional Programming. http://www.cl.cam.ac.uk/teaching/Lectures/funprog-jrh-1996/all.pdf [4] Edsger W. Dijkstra "The Structure of 'THE'--Multiprogramming System" Commun. ACM 11 (1968), 5:341–346. http://www.cs.utexas.edu/users/EWD/ewd01xx/EWD196.PDF
Re: Fwd: Building gcc-4.9 on OpenBSD
None of this is useful to me. I'm trying to make a case for why people should have confidence in GNU software. You are NOT helping me in that, I assure you, We need to publish some simple steps that people can take to reassure themselves that the 64MB binaries that GCC 4.9 produces on Linux systems are normal and nothing to worry about, Why is that so hard? Where are the GCC experts on this list. Where are the people that actually care about the reputation of the FSF? Ian On Fri, Sep 19, 2014 at 7:15 PM, Jonathan Wakely wrote: > On 20 September 2014 00:01, Jonathan Wakely wrote: >> On 19 September 2014 16:21, Ian Grant wrote: >>> Thanks. But I asked what the non-vanilla sources were. I know what >>> the vanilla sources are, because I'm using them! >> >> The non-vanilla sources are everything else. That should be pretty obvious. > > Or as it says in the text you quoted: > > "This is in contrast to modified source from distribution for instance > that will usually add some patches" > > Vanilla source == unmodified source > > Non-vanilla source == modified source > > Any modified source. If OpenBSD modifies the source, it's non-vanilla. > If Debian modifies the source, it's non-vanilla. > > Personally I don't like the terms vanilla and non-vanilla but I think > their meanings are fairly clear.
Re: Fwd: Building gcc-4.9 on OpenBSD
Thanks Andrew! You get first prize for most informative intelligent answer so far! Careful, you might get second prize too :-) The problem is that we need to find a way to tell people _what_ is in that "dwarf" code. Open BSD's gcc ignores it, prints a warning, and goes about its business. That's probably why OpenBSD gcc 4.9 binaries are 17MB against the 64MB compiled by gcc 4.9. But that is a really fucking big dwarf they're stuffing in threre. What is the data, really? We can't just say "it's dwarf" because that doesn't really mean a whole lot, does it? Thanks again for your helpful response. This is progress. Ian On Fri, Sep 19, 2014 at 8:04 PM, Andrew Pinski wrote: > On Fri, Sep 19, 2014 at 4:52 PM, Ian Grant > wrote: >> None of this is useful to me. I'm trying to make a case for why people >> should have confidence in GNU software. You are NOT helping me in >> that, I assure you, > > Again, try stripping out debugging information and look at the numbers > again. Or better yet use size printing out all of the sections rather > than the default output which combines some section and does not show > the debugging information, > > From a different email: >> > BTW, if "size" is reporting much smaller size than the executable >> > file itself and that motivates this concern, most of the difference >> > is likely to be debug info, which is bigger since gcc switched to >> > C++. Might want to try "strip". > >> Great. As I said, the exercise we are here engaged in is to convince >> as many people as possible that GCC does NOT suffer from this problem >> on any OS, either OS, Windows, OpenBSD, FreeBSD, Solaris, or Linux on >> any arch., including IBM System z. > > Then don't use size with the default options but rather with the sysv > style output (-A) and look at all of the sections. > > >> >> We need to publish some simple steps that people can take to reassure >> themselves that the 64MB binaries that GCC 4.9 produces on Linux >> systems are normal and nothing to worry about, > > Debugging information is increasing a lot. Writing GCC in C++ has > caused this issue because there is no removing of debugging > information yet in dwarf2/3/4, I think there is plans for it but I > can't remember if it made it into dwarf5 or not. > > Thanks, > Andrew Pinski > >> >> Why is that so hard? Where are the GCC experts on this list. Where are >> the people that actually care about the reputation of the FSF? >> >> Ian >> >> >> On Fri, Sep 19, 2014 at 7:15 PM, Jonathan Wakely >> wrote: >>> On 20 September 2014 00:01, Jonathan Wakely wrote: >>>> On 19 September 2014 16:21, Ian Grant wrote: >>>>> Thanks. But I asked what the non-vanilla sources were. I know what >>>>> the vanilla sources are, because I'm using them! >>>> >>>> The non-vanilla sources are everything else. That should be pretty obvious. >>> >>> Or as it says in the text you quoted: >>> >>> "This is in contrast to modified source from distribution for instance >>> that will usually add some patches" >>> >>> Vanilla source == unmodified source >>> >>> Non-vanilla source == modified source >>> >>> Any modified source. If OpenBSD modifies the source, it's non-vanilla. >>> If Debian modifies the source, it's non-vanilla. >>> >>> Personally I don't like the terms vanilla and non-vanilla but I think >>> their meanings are fairly clear.
Re: Dijkstra's Methodology for Secure Systems Development
The following is a response to what some may think an implausible suggestion made here: http://lists.gnu.org/archive/html/guile-devel/2014-09/msg00124.html The suggestion is that the system of education has been subverted so that there are "unknown" physical laws which give "the unseen enemy" strange powers over the semantics of computer hardware and software. http://livelogic.blogspot.com/2014/09/subverting-laws-of-physics.html I make what I think most people will see to be a convincing argument that this is in fact the case.
Verifying Toolchain Semantics
Dear programming language types, I wrote this to try once again to explain what is the nature of the problem that one would have in verifying the integrity of _any_ software toolchain, whether it is aimed ultimately at the production of other software, or of hardware. http://livelogic.blogspot.com/2014/10/the-foundation-part-i.html This three page text is ostensively about verifying the integrity of a communications link operating over an un-trusted transport layer, but a compiler is really a type of communications channel. I am sure everyone still reading this has wondered about the possibilities of using universal programming languages (universal in the Church-Turing sense) as communications protocols. For example, one could establish a point-to-point connection by writing a program which, when run, output two more programs: one which, when run, outputs a decoding pad for the next mesage one would transmit over that channel, and the other the decoder which prints the message text together with another program, which was the encoder for returning an acknowledgement. Both endpoints would do this, and so the programs/messages would be exchanged, with each one encoding the text of the other. Then these programs could include decisions not only about the encoding of data, choice of one-time pads, etc. but perhaps also the routes of messages, sending different parts via different trusted routes over similar channels etc. etc. The variations are endless, and limited only by the ingenuity of the programmers communicating over those channels. And really, I sorely pity anyone charged with organising any kind of surveillance of a group of people who enjoy that sort of game. Cracking "the code" would be practically impossible, because there need never be any fixed concrete representation whatsoever of the fundamental encoding as it is transmitted over the transport medium: _all_ of the knowledge about the current and future encodings can be sent over the previous "incarnations" of that and/or another channel, and the encoding of channels thereby made non-deterministic: this means that there could never be _in principle,_ any mechanical process _whatsoever_ which could decode more than a few parts of any of those messages. After this brief success, the poor would-be spy would be right back at square one. What I try to explain here is the essential distinction between what I call _actual knowledge,_ as opposed to mere _represented knowledge,_ such as a password, or an SSL certificate, or the documentation for some file format appearing on a web page. The distinction is that only in the case of actual knowledge does one know _how_ and _why_ one knows. The motivation is the idea that by using actual rather than represented knowledge, it is possible to construct such a trustworthy system in practice. But there's a catch! The catch is that this will only work for an organisation whose motives and governance are completely open and transparent. This is because the technique relies upon mutual trust, which is something that cannot exist without openness and transparency. Bad guys just won't get it! To understand why (in case it is not immediately obvious to you, that is) you will need to read (or at least think carefully about) about how error-detection would work in such a system. The text consists of a title page with the abstract, and two full pages. So it should be an easy read. I earlier sent out a nine page document entitled GNU Thunder, in which I attempted to describe what I consider to be essentially the same idea, but with the emphasis on compilers and interpreters, rather than communications. The Thunder text was a concrete suggestion for an implementation. This text however is more abstract. But these two documents could be considered to be complementary in two different senses. I hope everyone enjoys this, and that it stimulates some interesting thoughts, and subsequent discussion, and that those thoughts are all good, and the discussion open and transparent. That way we could save ourselves an awful lot of _really hairy_ metaprogramming! Please feel free to copy either text and/or this message and pass it around. Neither of these two texts are copyright, and the more people that see them the better. Bad guys in particular need to know about this much more than the good ones do. Ian
