Email list hosting service & mailing list manager

SRFI 176: Version flag Arthur A. Gleckler (07 Oct 2019 05:01 UTC)
Re: SRFI 176: Version flag John Cowan (07 Oct 2019 18:43 UTC)
Re: SRFI 176: Version flag Lassi Kortela (07 Oct 2019 20:26 UTC)
Re: SRFI 176: Version flag John Cowan (07 Oct 2019 20:50 UTC)
Re: SRFI 176: Version flag Lassi Kortela (07 Oct 2019 21:42 UTC)
Re: SRFI 176: Version flag John Cowan (07 Oct 2019 22:49 UTC)
Re: SRFI 176: Version flag Lassi Kortela (11 Oct 2019 23:40 UTC)
Re: SRFI 176: Version flag Arthur A. Gleckler (13 Oct 2019 03:40 UTC)
Re: SRFI 176: Version flag John Cowan (13 Oct 2019 04:23 UTC)
Re: SRFI 176: Version flag Arthur A. Gleckler (13 Oct 2019 04:53 UTC)
Re: SRFI 176: Version flag John Cowan (15 Oct 2019 12:20 UTC)
Storing manual pages and other data in executables Lassi Kortela (16 Oct 2019 20:39 UTC)
Re: Storing manual pages and other data in executables John Cowan (16 Oct 2019 21:36 UTC)
Re: SRFI 176: Version flag Shiro Kawai (13 Oct 2019 05:24 UTC)
Storing manual pages and other data in executables Lassi Kortela (14 Oct 2019 11:56 UTC)
Re: Storing manual pages and other data in executables John Cowan (14 Oct 2019 16:33 UTC)
Re: Storing manual pages and other data in executables Lassi Kortela (17 Oct 2019 17:06 UTC)
Gory details of parsing Lassi Kortela (07 Oct 2019 21:04 UTC)
Re: Gory details of parsing John Cowan (07 Oct 2019 23:05 UTC)
Re: Gory details of parsing Lassi Kortela (11 Oct 2019 23:50 UTC)
Re: Gory details of parsing John Cowan (15 Oct 2019 01:52 UTC)
Working out the platform and compiler info Lassi Kortela (14 Oct 2019 16:52 UTC)
Clarification of tuples Lassi Kortela (14 Oct 2019 17:09 UTC)
Re: Working out the platform and compiler info John Cowan (14 Oct 2019 18:07 UTC)

Storing manual pages and other data in executables Lassi Kortela 16 Oct 2019 20:39 UTC

>> There's been a discussion recently on the OSI mailing lists of including
>> the source code to GPLed programs as a mountable file system executable
>> inside the ELF image.  The general feeling was that people wouldn't be
>> inclined to trust such tools, since they would be only rarely used.
>
> That's an interesting idea, although I wouldn't trust it without a way to
> verify that the executable code matched the source code.

You'd have to include the source code of the compiler and build tools
used to compile the executable. Then the recipient could verify the
source code by compiling the compiler and using the compiled compiler to
compile the application program to find out whether the binary matches.
It probably wouldn't match due to system-specific differences, so the
image would need to include the build environment for the compiler...
soon we're at <http://bootstrappable.org/> :)

On a more serious note, practically all security is based on a
web-of-trust model. Even physical security - if you put things in a safe
you have to trust the people who built the safe, etc. It's not practical
to do much real verification by yourself - just cursory inspection.
Cryptographic hashes are simple and effective, but again you have to
trust whoever sent the hash.

Aside from that, it would be interesting to find out the size of the
`gcc` executable or the Linux kernel with the full source code included.