[License-discuss] [Non-DoD Source] Re: Storing source artifacts in ELF files

Karan, Cem F CIV USARMY CCDC ARL (USA) cem.f.karan.civ at mail.mil
Mon Oct 7 21:44:49 UTC 2019


Thorsten Glaser wrote on Monday, October 7, 2019 5:14 PM:
> To: license-discuss at lists.opensource.org
> Subject: [Non-DoD Source] Re: [License-discuss] Storing source artifacts in ELF files
> 
> Karan, Cem F CIV USARMY CCDC ARL (USA) via License-discuss dixit:
> 
> >Yeah, but the advantage of having it in the ELF file is that you don't
> >need to execute the file to get at the source
> 
> ?!?!?!
> 
> JARs are PKZIP archives. You can use something like Info-ZIP unzip(1) to get at its contents. (We bundle the sources in them though so
> that the web application can serve its own source to users.)

ELFs aren't JARs; the same tricks don't apply here (but ones that are similar do).

> >SEAs require you to trust that the archive is not malicious.
> 
> This is true for all archive format… 

No.  There are plenty of archive formats that you don't execute directly, but execute a different program to access the contents of the archive (try executing a standard tar file directly, unless your systems has been configured to untar it and then execute it, it won't work).

> oooh and PKZIP, with its habit of duplicating information, has been exploited at least on Android
> multiple times already…

The program on Android is buggy then.  But that could be true of tar, and any other number of archivers.  SEAs just take that to a whole new level of pain, because now you need to trust an untrusted binary to work correctly for each and every incoming binary.

> … I personally like romfs (from Linux 2.0, dunno if it’s still in Linux), which would achieve mountability… but compression might be
> desirable… I extremely doubt a good standard can be chosen at all.

You're probably right about that; if nothing else, there would need to be a standard filesystem chosen, a standard location in the ELF file to put the information, etc., etc., etc.  I doubt that the good points of the idea outweigh the bad, but it's fun to think about!

> Which is why my long mail ended with the suggestion to not embed but use the packaging system to provide instead.

That *is* the best way, this is just a fun way to think about.

> “ah that reminds me, thanks for the stellar entertainment that you and certain other people provide on the Debian mailing lists │ sole
> reason I subscribed to them (I'm not using Debian anywhere) is the entertainment factor │ Debian does not strike me as a place for good
> humour, much less German admin-style humour” 

Your mail client couldn't have summed this entire thread up any better, even if you custom wrote the message for this thread! :D


Thanks,
Cem Karan

---
Other than quoted laws, regulations or officially published policies, the views expressed herein are not intended to be used as an authoritative state of the law nor do they reflect official positions of the U.S. Army, Department of Defense or U.S. Government.





More information about the License-discuss mailing list