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)
|
>> 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.