all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Danny Milosavljevic <dannym@scratchpost.org>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: 33300@debbugs.gnu.org
Subject: bug#33300: Automatically detecting binaries in source tarballs
Date: Thu, 8 Nov 2018 00:57:01 +0100	[thread overview]
Message-ID: <20181108005701.2e76fd3d@scratchpost.org> (raw)
In-Reply-To: <87zhult0fb.fsf@gnu.org>

[-- Attachment #1: Type: text/plain, Size: 1722 bytes --]

Hi,

I think it would be good to have guix check for closed-source binaries after
unpacking, automatically (including jar files with class files in them).

Even when I know that they are there, I sometimes forget to delete them.  In
the long run it could even auto-delete those, but I guess only after a looong
time of integration.

> > Aside, -ish: looks like most distributions there found out about this
> > file due to some failing sanity check. Perhaps we could add our own,
> > in ‘guix lint’ or at build time, to warn about ELF files and other
> > suspicious binaries in post-snippet sourceballs?  

That would be great.

> Commit b17004f9f9541acbd07b45e35222e431427bfde0 added a -Wl,-rpath flag;
> perhaps that was due to address an error in libImageProcessor.so
> detected by ‘validate-runpath’?
> 
> That said, we could have a post-unpack phase that fails when ELF files
> are found.  The problem is that there are exceptions, in particular
> “yogurt software” (compilers, mostly).  So we’d have to manually fix
> every exception.
> 
> > No idea if it's worth the trouble/performance hit/false-positive rate,
> > of course. That's for the ner^Wgods to decide.  
> 
> Yeah I wonder if it would be fruitful.

Marking known-good binaries (whitelisting) is still better than hoping
we notice some closed-source binary (blacklisting).

It would be a conspicious reminder of what we still have to do - as
opposed to the situation now where it's mostly in someone's head
(if at all).

Once we finish the bootstrapping effort, the source tarballs won't
need to contain any binaries anymore anyway :)

I wonder just how many whitelist entries that would be, though.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2018-11-07 23:58 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-07 10:19 bug#33300: hplip 3.18.9 contains non-free binary blobs Ludovic Courtès
2018-11-07 12:48 ` Efraim Flashner
2018-11-07 14:34   ` Ludovic Courtès
2018-11-07 13:09 ` Tobias Geerinckx-Rice
2018-11-07 14:41   ` Ludovic Courtès
2018-11-07 23:57     ` Danny Milosavljevic [this message]
2018-11-08  8:50       ` bug#33300: Automatically detecting binaries in source tarballs Ludovic Courtès
2018-11-08 23:11         ` Björn Höfling
2018-11-11  7:23           ` Efraim Flashner
2018-11-11 17:28             ` Ludovic Courtès
2018-11-11 17:30     ` bug#33300: hplip 3.18.9 contains non-free binary blobs Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20181108005701.2e76fd3d@scratchpost.org \
    --to=dannym@scratchpost.org \
    --cc=33300@debbugs.gnu.org \
    --cc=ludo@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.