gnu-linux-libre
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GNU-linux-libre] Good practices for removing nonfree code found in


From: Denis 'GNUtoo' Carikli
Subject: Re: [GNU-linux-libre] Good practices for removing nonfree code found in source code.
Date: Mon, 11 Oct 2021 18:13:41 +0200

On Sun, 10 Oct 2021 15:25:09 +0300
Jean Louis <bugs@gnu.support> wrote:

> * Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org> [2021-10-06
> 23:10]:
> > On Wed, 6 Oct 2021 17:35:43 +0300
> > Jean Louis <bugs@gnu.support> wrote:
> > > My idea is that software directory and similar projects should
> > > provide digital, parsable database of software with their authors
> > > and original servers of software distributions, then all
> > > distributions could access such centralized database and choose
> > > by category and other tags and facts, which software they wish to
> > > include in their distribution. Information should be there which
> > > provides more authenticity of the origin of software. PGP keys
> > > are really not enough there. Like you said, if software comes
> > > from Samsung and from Samsung website, that is pretty authentic,
> > > not absolute, but it becomes reasonable.
> > For Authors, in many cases, like with Linux, not all authors are
> > known, but instead the copyrights are known.
> 
> And that is what I am saying that is risky. If recipient of any work
> does not know author or copyright holder who need not be author,
> then in court cases in some countries, not all, it would not, could
> not be defense.
I don't see why that doesn't work. 

In most case, employees don't own the copyright, the company does.

It would be best if the copyright was the employee's as they could help
better enforce copyleft licenses, and potentially give them more
leverage against companies abuses of power, but in the case of a
downstream recipient of source code that is free software and does
respect the free software license, I see nothing problematic. 

And even if I'm not a lawyer, I know a bit the rough consensus that
there is in the free and open source communities and I never heard of
issues for downstream users of code licensed by companies under free
software license whose copyright is well known but authors aren't.

So if you know court cases about that, with precise enough references to
enable me to find more information on the court cases, I would be really
interested in them. If you also have good analysis on them I would also
be very interested.

> > For source I don't think there is much beside the usual checksums
> > and/or gpg verification in all the distributions I looked at.
> 
> GPG verifications also mean nothing much as majority of users don't
> follow PGP guidelines. It is false sense of security to only verify
> that fingerprint matches the key. What one has to verify is the person
> who claims to have that PGP key, and for that person to confirm the
> fingerprint. If you have not verified person, the fingerprint of the
> key Donald Trump will be correct, but it wasn't Donald Trump in the
> first place.
In Parabola it's not users who verify the GPG signatures but
developers. It's probably the same with all other distributions.

The linux-libre PKGBUILD has that for instance:
> validpgpkeys=(
>   '474402C8C582DAFBE389C427BCB7CF877E7D47A7' # Alexandre Oliva
>   '6DB9C4B4F0D8C0DC432CF6E4227CA7C556B2BA78' # David P.
> )

How well that's verified probably depends on the individual developers.

Some developers might also already have interacted with Alexandre by
encrypted or signed mail, or met both developers. In that cases like
that, the risk is pretty low. And David P. is a Parabola developer, so
Parabola already trust David's key and since David also worked on this
package he should know the hash of his key and also be aware that his
key hash is in that package definition.

However I doubt that every individual developers know everybody or does
extensive checks on every source code. 

When we are not in such ideal cases, the more different people build the
source packages or work on them, the more assurance we have that the
source code is the right one. And that also works for cases where there
is no gpg keys but only checksums in the various packages definitions.

I'm not aware of any Parabola package or Arch Linux package used by
Parabola that doesn't at least have checksums with sha1 or better.

There are project about reproducible builds, so I don't see anything
wrong about people helping distributions with checking that the
tarballs are valid by building the packages and warning distributions if
something is really problematic.

If I recall well, we already had a case where a maintainer silently
updated already released source code to fix a bug, and some Tor exit
nodes also were caught modifying binaries[3].

If you do that kind of work, or setup infrastructure that does it
automatically, it might also be useful to partner with projects like Tor
to help flag problematic exit nodes along the way.

References:
-----------
[1]https://www.fsf.org/blogs/licensing/fsf-to-begin-accepting-gpg-signatures-for-copyright-assignments-from-italy
[2]https://www.fsf.org/blogs/licensing/fsf-to-begin-accepting-gpg-signed-assignments-from-the-u-s
[3]https://www.leviathansecurity.com/blog/the-case-of-the-modified-binaries/

Denis.

Attachment: pgpMdkjgyOcMP.pgp
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]