Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.project > #9658 > unrolled thread

Automatic downloading of non-free software by stuff in main

Back to article view | Back to linux.debian.project

Contents

  Automatic downloading of non-free software by stuff in main Ian Jackson <ijackson@chiark.greenend.org.uk> - 2017-11-30 15:00 +0100
    Re: Automatic downloading of non-free software by stuff in main Ian Jackson <ijackson@chiark.greenend.org.uk> - 2017-12-01 15:00 +0100
      Re: Automatic downloading of non-free software by stuff in main Andrey Rahmatullin <wrar@debian.org> - 2017-12-01 16:30 +0100
        Re: Automatic downloading of non-free software by stuff in main Enrico Zini <enrico@enricozini.org> - 2017-12-01 16:40 +0100
          Re: Automatic downloading of non-free software by stuff in main Andrey Rahmatullin <wrar@debian.org> - 2017-12-01 17:20 +0100
            Re: Automatic downloading of non-free software by stuff in main Ian Jackson <ijackson@chiark.greenend.org.uk> - 2017-12-01 17:30 +0100
          Re: Automatic downloading of non-free software by stuff in main Ian Jackson <ijackson@chiark.greenend.org.uk> - 2017-12-01 17:20 +0100
        Re: Automatic downloading of non-free software by stuff in main "G. Branden Robinson" <g.branden.robinson@gmail.com> - 2017-12-01 19:10 +0100
      Re: Automatic downloading of non-free software by stuff in main Adam Borowski <kilobyte@angband.pl> - 2017-12-01 18:20 +0100
        Re: Automatic downloading of non-free software by stuff in main Ian Jackson <ijackson@chiark.greenend.org.uk> - 2017-12-01 18:30 +0100
        Re: Automatic downloading of non-free software by stuff in main "G. Branden Robinson" <g.branden.robinson@gmail.com> - 2017-12-01 19:10 +0100
          Re: Automatic downloading of non-free software by stuff in main Adam Borowski <kilobyte@angband.pl> - 2017-12-01 20:10 +0100
          Re: Automatic downloading of non-free software by stuff in main Tollef Fog Heen <tfheen@err.no> - 2017-12-03 12:10 +0100
    Re: Automatic downloading of non-free software by stuff in main "Dr. Bas Wijnen" <wijnen@debian.org> - 2017-12-03 09:00 +0100
    Re: Automatic downloading of non-free software by stuff in main Diane Trout <diane@ghic.org> - 2017-12-05 21:50 +0100
      Re: Automatic downloading of non-free software by stuff in main Andrey Rahmatullin <wrar@debian.org> - 2017-12-06 05:10 +0100
        Re: Automatic downloading of non-free software by stuff in main Ben Hutchings <ben@decadent.org.uk> - 2017-12-06 07:50 +0100
          Re: Automatic downloading of non-free software by stuff in main Henrique de Moraes Holschuh <hmh@debian.org> - 2017-12-07 00:40 +0100
            Re: Automatic downloading of non-free software by stuff in main Ben Hutchings <ben@decadent.org.uk> - 2017-12-07 01:10 +0100
              Re: Automatic downloading of non-free software by stuff in main Michael Stone <mstone@debian.org> - 2017-12-07 01:20 +0100
                Re: Automatic downloading of non-free software by stuff in main Ben Hutchings <ben@decadent.org.uk> - 2017-12-07 02:40 +0100
                  Re: Automatic downloading of non-free software by stuff in main Adam Borowski <kilobyte@angband.pl> - 2017-12-07 03:30 +0100
                    Re: Automatic downloading of non-free software by stuff in main Mike Hommey <mh@glandium.org> - 2017-12-07 04:20 +0100
                      Re: Automatic downloading of non-free software by stuff in main Andrey Rahmatullin <wrar@debian.org> - 2017-12-07 07:10 +0100
                      Re: Automatic downloading of non-free software by stuff in main Diane Trout <diane@ghic.org> - 2017-12-07 07:20 +0100
                    Re: Automatic downloading of non-free software by stuff in main Andrey Rahmatullin <wrar@debian.org> - 2017-12-07 14:00 +0100
                      Re: Automatic downloading of non-free software by stuff in main Holger Levsen <holger@layer-acht.org> - 2017-12-07 14:10 +0100
                        Re: Automatic downloading of non-free software by stuff in main Paul Wise <pabs@debian.org> - 2017-12-07 14:20 +0100
                        Re: Automatic downloading of non-free software by stuff in main "Paul R. Tagliamonte" <paultag@gmail.com> - 2017-12-07 14:40 +0100
                          Re: Automatic downloading of non-free software by stuff in main Ian Jackson <ijackson@chiark.greenend.org.uk> - 2017-12-07 15:00 +0100
                            Re: Automatic downloading of non-free software by stuff in main Holger Levsen <holger@layer-acht.org> - 2017-12-07 15:00 +0100
                              Re: Automatic downloading of non-free software by stuff in main Lars Wirzenius <liw@liw.fi> - 2017-12-07 15:50 +0100
                            Re: Automatic downloading of non-free software by stuff in main "Paul R. Tagliamonte" <paultag@gmail.com> - 2017-12-07 15:20 +0100
                              Re: Automatic downloading of non-free software by stuff in main Ian Jackson <ijackson@chiark.greenend.org.uk> - 2017-12-07 17:10 +0100
                                technical terms (Re: Automatic downloading of non-free software by  stuff in main) Holger Levsen <holger@layer-acht.org> - 2017-12-07 18:00 +0100
                                  technical terms (Re: Automatic downloading of non-free software by  stuff in main) Ian Jackson <ijackson@chiark.greenend.org.uk> - 2017-12-07 18:30 +0100
                                Re: Automatic downloading of non-free software by stuff in main Jonas Smedegaard <dr@jones.dk> - 2017-12-07 18:30 +0100
                                Re: Automatic downloading of non-free software by stuff in main "Paul R. Tagliamonte" <paultag@gmail.com> - 2017-12-07 18:40 +0100
                                  Re: Automatic downloading of non-free software by stuff in main Diane Trout <diane@ghic.org> - 2017-12-07 19:40 +0100
                                  Re: Automatic downloading of non-free software by stuff in main Adam Borowski <kilobyte@angband.pl> - 2017-12-07 22:10 +0100
                                    Re: Automatic downloading of non-free software by stuff in main Diane Trout <diane@ghic.org> - 2017-12-07 23:00 +0100
                                    Re: Automatic downloading of non-free software by stuff in main "Paul R. Tagliamonte" <paultag@gmail.com> - 2017-12-07 23:10 +0100
                          Re: Automatic downloading of non-free software by stuff in main gregor herrmann <gregoa@debian.org> - 2017-12-07 19:30 +0100
                            Re: Automatic downloading of non-free software by stuff in main Diane Trout <diane@ghic.org> - 2017-12-07 20:10 +0100
                              Re: Automatic downloading of non-free software by stuff in main Andrey Rahmatullin <wrar@debian.org> - 2017-12-07 20:30 +0100
                                Re: Automatic downloading of non-free software by stuff in main Diane Trout <diane@ghic.org> - 2017-12-07 21:10 +0100
                    Re: Automatic downloading of non-free software by stuff in main Holger Levsen <holger@layer-acht.org> - 2017-12-07 14:00 +0100
      Automatically marking downloaded files (was Re: Automatic downloading  of non-free software by stuff in main) Anthony DeRobertis <anthony@derobert.net> - 2017-12-06 06:30 +0100
        Re: Automatically marking downloaded files (was Re: Automatic downloading of non-free software by stuff in main) Stuart Prescott <stuart@debian.org> - 2017-12-07 02:40 +0100
          Re: Automatically marking downloaded files (was Re: Automatic downloading of non-free software by stuff in main) Ian Jackson <ijackson@chiark.greenend.org.uk> - 2017-12-07 15:00 +0100

Page 1 of 3  [1] 2 3  Next page →

#9658 — Automatic downloading of non-free software by stuff in main

This mail is going to a lot of lists.  I have set the followups to
d-policy because ultimately this is hopefully going to result in a
change to policy.


Over the years, d-legal has discussed a number of packages which
automatically download non-free software, under some circumstances.

The obvious example is web browsers with extension repositories
containing both free and non-free software.

We have also recently discussed a media downloader/player which, when
fed a particular kind of url, will offer to automatically download a
proprietary binary-only protocol module to access the specified
proprietary web service.

We have generally put software like this in main, because it asks the
user first, and can be used perfectly well without the proprietary
parts.  But the overall result is that a user who wants to use Free
software can be steered by Debian into installing and using non-free
software, sometimes unwittingly,

I would like to establish a way to prevent this.  (There are even
whole Debian derivatives who have as one of their primary goals,
preventing this.  We should aim for most of the changes necessary for
such derivatives to be in Debian proper, so the derivative can be
little more than a change to the default configuration.)

I think the necessary new central technical component is a
configuration somewhere, checked by programs with plugin download
capability.

We should have a conversation about:

 * What user experience options should ideally be available
 * How those options should be represented in configuration
 * Bug severity for programs that do not respect the "only free
   stuff" setting.

Ideally we can come up with a technical solution which means that it
is easy for existing programs implement the new check, so that failure
to do so can be RC for buster.

The minimum required changes to individual packages should be small.

NB that this is going to be a _user option_.  I'm not trying to shut
down non-free extension repositories.  (Indeed I sometimes use them.)
I want to give users more control.


Obviously excluded from this discussion are downloader packages, which
have the fetching and use of proprietary things as their primary
purpose, and which therefore live in contrib.


But there is another category I want to distinguish:

Applications for processing Turing-complete file formats.  This
includes web browsers, because of Javascript; but it also includes
PostScript viewers; interactive fiction interpreters; and so on.

The distinction between this and the general plugins I mention above
is that these applications all restrict the capabilities of the code
being executed, by running it in some kind of sandbox or container.
The idea being that the code gets to control the user's interactions
_with the providers of that code_, but not anything else.

There are some people who object to executing any non-free code on
their computer and I don't mind providing a facility for people to
restrict that.  But I don't know exactly how to design such a thing.

For web browsers, there is the FSF's libre-JS.  Personally I think
that is rather quixotic (and doesn't really address the real user
freedom question anyway), but I have no objection if anyone wants to
do the work to integrate that into some kind of freeness control
system.

But with file formats, the situation is much harder.  I don't feel we
can introduce a policy requirement requiring package maintainers to
support users who want this kind of restriction, until we can come up
with a scheme that will actually work and be useable (and indeed, will
be minimal effort for a package maintainer to opt into).

(The question is: how do we stop a Postscript file received by email
being rendered automatically when the user clicks on it, while
allowing the user to still open a Postscript file they generated
themselves ?)


Ian.

-- 
Ian Jackson <ijackson@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

[toc] | [next] | [standalone]

#9660

(Dropping the crossposts.  The stuff I want to reply to is probably
material for -project.)

Adam Borowski writes ("Re: Automatic downloading of non-free software by stuff in main"):
> On Thu, Nov 30, 2017 at 01:52:18PM +0000, Ian Jackson wrote:
> > I would like to establish a way to prevent this.  (There are even
> > whole Debian derivatives who have as one of their primary goals,
> > preventing this.
> 
> No, those derivatives are damage.  While their hearts are in the right
> place, they cause data loss and security holes by at least making people on
> Intel and AMD machines use known-buggy microcode.

I think it's very rude to call something damage just because you
disagree with someone's political stance with respect to the software
they un on their own computer.

Also, if you care so much about this you should probably worry about
Debian's current default approach to microcode.

> The biggest reason for me

Debian ought to be a good upstream for everyone, not just "me"
(whoever me is).

Ian.

[toc] | [prev] | [next] | [standalone]

#9661

[Multipart message — attachments visible in raw view] — view raw

On Fri, Dec 01, 2017 at 01:53:22PM +0000, Ian Jackson wrote:
> > > I would like to establish a way to prevent this.  (There are even
> > > whole Debian derivatives who have as one of their primary goals,
> > > preventing this.
> > 
> > No, those derivatives are damage.  While their hearts are in the right
> > place, they cause data loss and security holes by at least making people on
> > Intel and AMD machines use known-buggy microcode.
> 
> I think it's very rude to call something damage just because you
> disagree with someone's political stance with respect to the software
> they un on their own computer.
Adam spoke about derivative users, not derivative developers, though.

> Also, if you care so much about this you should probably worry about
> Debian's current default approach to microcode.
We do. But it will require a GR and a flamewar to fix things, most likely.

> > The biggest reason for me
> 
> Debian ought to be a good upstream for everyone, not just "me"
> (whoever me is).
Our users are declared our priority, our downstreams aren't.

-- 
WBR, wRAR

[toc] | [prev] | [next] | [standalone]

#9662

[Multipart message — attachments visible in raw view] — view raw

On Fri, Dec 01, 2017 at 08:22:58PM +0500, Andrey Rahmatullin wrote:

> > Debian ought to be a good upstream for everyone, not just "me"
> > (whoever me is).
> Our users are declared our priority, our downstreams aren't.

It never occurred to me that our downstreams could be considered as not
being a part of our users. Is that a common understanding?


Enrico

-- 
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini <enrico@enricozini.org>

[toc] | [prev] | [next] | [standalone]

#9663

[Multipart message — attachments visible in raw view] — view raw

On Fri, Dec 01, 2017 at 04:10:46PM +0000, Ian Jackson wrote:
> > > > Debian ought to be a good upstream for everyone, not just "me"
> > > > (whoever me is).
> > > Our users are declared our priority, our downstreams aren't.
> > 
> > It never occurred to me that our downstreams could be considered as not
> > being a part of our users. Is that a common understanding?
> 
> I hope not!  I consider all the users of all our downstreams, as users
> of Debian.
You are changing the topic, as initially you were talking about helping
the downstream *developers* (by adding extra complexity to Debian).

-- 
WBR, wRAR

[toc] | [prev] | [next] | [standalone]

#9665

Andrey Rahmatullin writes ("Re: Automatic downloading of non-free software by stuff in main"):
> > > > Our users are declared our priority, our downstreams aren't.
> > > 
> > > It never occurred to me that our downstreams could be considered as not
> > > being a part of our users. Is that a common understanding?
> > 
> > I hope not!  I consider all the users of all our downstreams, as users
> > of Debian.
> You are changing the topic, as initially you were talking about helping
> the downstream *developers* (by adding extra complexity to Debian).

I see no real distinction in general between helping users of our
downstreams, and helping the developers of those downstreams.  Often
they are the same people.  When they aren't, the downstream users have
chosen the downstream developers, and delegated a lot of things to the
developers of their operating system.  If we respect that delegation,
we respect those users.

Of course there could be exceptions, where a downstream's developers
take an unethical approach to their users.  But I don't think that a
particular highly-publicised stance towards non-free components can
fall into that category.  The users who have chosen such derivatives
have done so _because_ of that stance.  We serve those users if we
make their wishes easier to implement.

Ian.

-- 
Ian Jackson <ijackson@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

[toc] | [prev] | [next] | [standalone]

#9664

Enrico Zini writes ("Re: Automatic downloading of non-free software by stuff in main"):
> On Fri, Dec 01, 2017 at 08:22:58PM +0500, Andrey Rahmatullin wrote:
> > [Ian Jackson:]
> > > Debian ought to be a good upstream for everyone, not just "me"
> > > (whoever me is).
> > Our users are declared our priority, our downstreams aren't.
> 
> It never occurred to me that our downstreams could be considered as not
> being a part of our users. Is that a common understanding?

I hope not!  I consider all the users of all our downstreams, as users
of Debian.

Ian.

-- 
Ian Jackson <ijackson@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

[toc] | [prev] | [next] | [standalone]

#9669

[Multipart message — attachments visible in raw view] — view raw

At 2017-12-01T20:22:58+0500, Andrey Rahmatullin wrote:
> Adam spoke about derivative users, not derivative developers, though.
[...]
> Our users are declared our priority, our downstreams aren't.

This is a false dilemma and I urge our community to reject it.

-- 
Regards,
Branden

[toc] | [prev] | [next] | [standalone]

#9666

On Fri, Dec 01, 2017 at 01:53:22PM +0000, Ian Jackson wrote:
> (Dropping the crossposts.  The stuff I want to reply to is probably
> material for -project.)

Thanks, crossposts are bad!

> Adam Borowski writes ("Re: Automatic downloading of non-free software by stuff in main"):
> > On Thu, Nov 30, 2017 at 01:52:18PM +0000, Ian Jackson wrote:
> > > I would like to establish a way to prevent this.  (There are even
> > > whole Debian derivatives who have as one of their primary goals,
> > > preventing this.
> > 
> > No, those derivatives are damage.  While their hearts are in the right
> > place, they cause data loss and security holes by at least making people on
> > Intel and AMD machines use known-buggy microcode.
> 
> I think it's very rude to call something damage just because you
> disagree with someone's political stance with respect to the software
> they un on their own computer.

While their _intent_ is good, they are telling others to run software with
known severe bugs.  Microcode itself has data loss and local exploits (such
as an unprivileged user of an unprivileged VM taking over the host machine),
then often comes in one bunch with IME updates that close remote holes.
And once remote holes come into play, it's no longer a matter of just what's
running on your own computer.

> Also, if you care so much about this you should probably worry about
> Debian's current default approach to microcode.

Right.

> > The biggest reason for me
> 
> Debian ought to be a good upstream for everyone, not just "me"
> (whoever me is).

I'm talking about explanations, not options Debian provides to users.

It looks like we two are in agreement that all non-free software is bad,
even if we differ wrt how acceptable using it is.  But we disagree about
the reason _why_:

* I say that the primary reason is that a person not blessed by the upstream
  has no way to fix problems.  You can't debug Windows Update to see why
  your aunt's computer hangs during it.  You can't print a cheat sheet of a
  GFDLed manual without the cover and invariant sections.  To me, every
  part of DFSG (other than 4.) solves a real _practical_ problem.

* the distributions you're talking about state this as a moral issue.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ Mozilla's Hippocritic Oath: "Keep trackers off your trail"
⣾⠁⢰⠒⠀⣿⡁ blah blah evading "tracking technology" blah blah
⢿⡄⠘⠷⠚⠋⠀ "https://click.e.mozilla.org/?qs=e7bb0dcf14b1013fca3820..."
⠈⠳⣄⠀⠀⠀⠀ (same for all links)

[toc] | [prev] | [next] | [standalone]

#9667

Adam Borowski writes ("Re: Automatic downloading of non-free software by stuff in main"):
> It looks like we two are in agreement that all non-free software is bad,
> even if we differ wrt how acceptable using it is.  But we disagree about
> the reason _why_:
> 
> * I say that the primary reason is that a person not blessed by the upstream
>   has no way to fix problems.  You can't debug Windows Update to see why
>   your aunt's computer hangs during it.  You can't print a cheat sheet of a
>   GFDLed manual without the cover and invariant sections.  To me, every
>   part of DFSG (other than 4.) solves a real _practical_ problem.
> 
> * the distributions you're talking about state this as a moral issue.

I don't see that this is a sensible distinction.  But anyway, it
doesn't matter.  People who use those downstreams are doing it because
they have decided that they agree with those downstreams' very zealous
objection to non-free software, including firmware etc.

I propose to help those users, and those downstream developers, by
doing some more of the work in Debian.

Ian.

-- 
Ian Jackson <ijackson@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

[toc] | [prev] | [next] | [standalone]

#9668

[Multipart message — attachments visible in raw view] — view raw

Hi Adam,

I think you're probably already away of the factual portions of my
claims below, but I'm making them for the benefit of the broader
audience.

At 2017-12-01T18:11:34+0100, Adam Borowski wrote:
> > > No, those derivatives are damage.  While their hearts are in the right
> > > place, they cause data loss and security holes by at least making people on
> > > Intel and AMD machines use known-buggy microcode.
[...]
> While their _intent_ is good, they are telling others to run software with
> known severe bugs.

It's wise to assume that all software that hasn't been formally _and_
independently verified has severe bugs.  And just because a bug is not
known to _you_ doesn't mean it isn't known to government snoops,
corporate revenue-maximizers, and criminals.

> Microcode itself has data loss and local exploits (such
> as an unprivileged user of an unprivileged VM taking over the host machine),
> then often comes in one bunch with IME updates that close remote holes.

And how do we know they aren't opening new ones due to the same factors
(bad design or bad intent) that led to the originals?

> And once remote holes come into play, it's no longer a matter of just what's
> running on your own computer.

We can be confident that all modern Intel- and AMD-based systems are
pre-compromised and running effectively hostile code fresh from the
factory.

1. https://libreboot.org/faq.html#intel
2. https://libreboot.org/faq.html#amd
3. https://lwn.net/Articles/738649/

-- 
Regards,
Branden

[toc] | [prev] | [next] | [standalone]

#9670

On Fri, Dec 01, 2017 at 01:07:59PM -0500, G. Branden Robinson wrote:
> Hi Adam,
> 
> I think you're probably already away of the factual portions of my
> claims below, but I'm making them for the benefit of the broader
> audience.
> 
> At 2017-12-01T18:11:34+0100, Adam Borowski wrote:
> > > > No, those derivatives are damage.  While their hearts are in the right
> > > > place, they cause data loss and security holes by at least making people on
> > > > Intel and AMD machines use known-buggy microcode.
> [...]
> > While their _intent_ is good, they are telling others to run software with
> > known severe bugs.
> 
> It's wise to assume that all software that hasn't been formally _and_
> independently verified has severe bugs.  And just because a bug is not
> known to _you_ doesn't mean it isn't known to government snoops,
> corporate revenue-maximizers, and criminals.

Earlier in this thread I wrote:

---
Yeah, opaque encrypted microcode can be used to sneak in new backdoors,
but that doesn't make past bugs (and "oh, those foul hackers found one of
our backdoors, it was a honest bug, really!") any better.  At the very
least, you get new TLA-only backdoors while those fixed are usable by both
TLAs and any random punk.

Likewise, closed firmware for your wifi card is evil, but still strictly
better than the same code burned into ROM: you get some bug fixes, and can
go back to a past version.  Sweeping non-free code under the carpet doesn't
help in any way -- if you have to use it, it's better kept where you can
see it.
---

It's the difference between suspected (but indeed likely) brand new holes
that are known to one corporation and a few spook agencies, vs old holes
which have been disseminated to a wide array of bad guys.  Plus, a long list
of non-intentional data loss bugs.

> > Microcode itself has data loss and local exploits (such
> > as an unprivileged user of an unprivileged VM taking over the host machine),
> > then often comes in one bunch with IME updates that close remote holes.
> 
> And how do we know they aren't opening new ones due to the same factors
> (bad design or bad intent) that led to the originals?
> 
> > And once remote holes come into play, it's no longer a matter of just what's
> > running on your own computer.
> 
> We can be confident that all modern Intel- and AMD-based systems are
> pre-compromised and running effectively hostile code fresh from the
> factory.

With this, I agree.

It looks like some alternatives have appeared recently, like Talos 2 that's
marketed as open (if you trust IBM), and fully free drivers (including the
equivalent of ME/PSP) for Pinebook have finally been posted (currently in a
form outside my u-boot/ATF/SPL skills, vagrantc is trying to figure it out).
But then, Talos is a wee bit pricey for a client machine, while Pinebook's
performance is abysmal.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ Mozilla's Hippocritic Oath: "Keep trackers off your trail"
⣾⠁⢰⠒⠀⣿⡁ blah blah evading "tracking technology" blah blah
⢿⡄⠘⠷⠚⠋⠀ "https://click.e.mozilla.org/?qs=e7bb0dcf14b1013fca3820..."
⠈⠳⣄⠀⠀⠀⠀ (same for all links)

[toc] | [prev] | [next] | [standalone]

#9672

]] "G. Branden Robinson" 

> At 2017-12-01T18:11:34+0100, Adam Borowski wrote:
> > Microcode itself has data loss and local exploits (such
> > as an unprivileged user of an unprivileged VM taking over the host machine),
> > then often comes in one bunch with IME updates that close remote holes.
> 
> And how do we know they aren't opening new ones due to the same factors
> (bad design or bad intent) that led to the originals?

This argument can be applied to any bug fix we or an upstream does, but
that doesn't mean we avoid shipping updated software.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

[toc] | [prev] | [next] | [standalone]

#9671

[Multipart message — attachments visible in raw view] — view raw

On Fri, Dec 01, 2017 at 06:09:12AM +0100, Adam Borowski wrote:
> On Thu, Nov 30, 2017 at 01:52:18PM +0000, Ian Jackson wrote:
> > Over the years, d-legal has discussed a number of packages which
> > automatically download non-free software, under some circumstances.
> > 
> > The obvious example is web browsers with extension repositories
> > containing both free and non-free software.
> > 
> > We have also recently discussed a media downloader/player which, when
> > fed a particular kind of url, will offer to automatically download a
> > proprietary binary-only protocol module to access the specified
> > proprietary web service.
> [...]
> > I would like to establish a way to prevent this.  (There are even
> > whole Debian derivatives who have as one of their primary goals,
> > preventing this.
> 
> No, those derivatives are damage.  While their hearts are in the right
> place, they cause data loss and security holes by at least making people on
> Intel and AMD machines use known-buggy microcode.

This is a different subject, though.  We had a discussion about software
supporting non-free hardware a while ago.  I'm still planning to propose a GR
for that, but have been distracted so it's taking a while.

What Ian is talking about is not "this software is non-free, but I need it
because I have hardware that won't run properly without it", but "this software
is non-free and my program from main just installs it on my computer".  Ian
didn't talk about hardware supporting software, so he didn't exclude it
explicitly, but I think we should do that.  Because with hardware you make
valid points, but they are irrelevant for pure software, such as the example of
a web browser downloading non-free add-ons.

I believe Ian's intent was to discuss the pure software problem (Ian, please
correct me if I'm wrong).  So if you want to talk about microcode and wifi
firmware, please do so in a different thread.

> Even Debian is not without fault here: for example, the ftpmasters accept
> such a blatantly non-free licence as AGPL[1] into main.

In today's digital environment, a lot of programs are moved from the user's
machine to a network service.  The purpose of the GPL is to give all downstream
users freedoms.  This can be circumvented by putting the code on a remote
server and never installing it on the user's machine, because the GPL only
talks about code that runs on the user's machine.  The AGPL fixes that problem
by requiring those hosting such programs to pass the freedoms on to their
networked users.  This is a necessary fix for a problem that didn't exist when
the GPL was originally written.

There may be some issues with the way it is written, but the fact that
networked users deserve the same rights as local users is self evident in
today's networked world.  So while you can advocate for minor modifications to
the license so that it becomes legally better, advocating against it entirely
is not reasonable IMO.

> [1]. AGPL fails FSF freedom 0: you can't reuse snippets of code from an
> AGPLed project in anything networked that has no, or cumbersome, ways to
> pass advertising statements to the user (such as, eg, an IMAP server).

The AGPL only says it must "prominently offer" an opportunity to receive the
source code.  I think it is possible to do this for example on the web site
that tells the users about the address of the server.  What "prominent" means
depends on how the service is normally used.  That's why they used such a
subjective description.

> It also fails the Dissident Test: take a blogging software with
> steganographic features, that you provide hosting for, for two classes of
> users: fellow dissidents, and public at large.  The former receive the code
> (both binaries and source), the latter do not.  Even revealing the existence
> of your changes is a serious risk for the life of you and your friends.
> Regular GPL has no such problems.

Yes, it does have these "problems" and they're the main difference between the
GPL and BSD-style licenses: the GPL requires users to have access to the source
code, so if you don't want your users to know that changes to the source were
made, you cannot let them run your code.

The AGPL closes the loophole that the GPL did not cover networked users.  But
if we take your example and run it locally (for example, make it a message
board on a multi-user machine that is used by students of a university in a
country with an oppressive regime), you have the exact same problem and with
your logic now the GPL is failing the dissident test.

I don't agree that it does.  For dissidents, just like anyone else, things are
easier without copyleft, because they are more free personally (at the cost of
the freedom of their users).  However, if they choose to host the software
without changes for the public and an extra copy with changes for fellow
dissidents, there should be no problem.

Thanks,
Bas

[toc] | [prev] | [next] | [standalone]

#9673

[Multipart message — attachments visible in raw view] — view raw

On Thu, 2017-11-30 at 13:52 +0000, Ian Jackson wrote:
> (The question is: how do we stop a Postscript file received by email
> being rendered automatically when the user clicks on it, while
> allowing the user to still open a Postscript file they generated
> themselves ?)

I wanted to highlight that this would be a very useful feature even
beyond the proposed use case of helping handle download non-free
software.

I would love for files downloaded via a web browser or email client to
be marked as having come from the Internet. (Major bonus points if a
sync tool like nextcloud can keep files I generated labeled separate
from ones my coworkers made)

OS X web browsers do this, and when you try to open them the OS will
prompt "this came from the internet, do you want to open it". It looks
like its implemented with a few extended attributes. [1]

Do most of our file systems have extended attributes turned on by now?

Has anyone tried to implement this yet? It seems like a small library
in the freedesktop.org umbrella, and a fair amount of trying to
convince other projects to adopt it.

Diane

[1] https://www.quora.com/How-does-OS-X-mark-files-as-downloaded-from-t
he-Internet

[toc] | [prev] | [next] | [standalone]

#9674

[Multipart message — attachments visible in raw view] — view raw

On Tue, Dec 05, 2017 at 12:48:36PM -0800, Diane Trout wrote:
> I would love for files downloaded via a web browser or email client to
> be marked as having come from the Internet. (Major bonus points if a
> sync tool like nextcloud can keep files I generated labeled separate
> from ones my coworkers made)
> 
> OS X web browsers do this, and when you try to open them the OS will
> prompt "this came from the internet, do you want to open it". It looks
> like its implemented with a few extended attributes. [1]
Windows too (implemented with NTFS alternate data streams).

> Do most of our file systems have extended attributes turned on by now?
I think (or at least hope) so.

-- 
WBR, wRAR

[toc] | [prev] | [next] | [standalone]

#9676

[Multipart message — attachments visible in raw view] — view raw

On Wed, 2017-12-06 at 09:09 +0500, Andrey Rahmatullin wrote:
> On Tue, Dec 05, 2017 at 12:48:36PM -0800, Diane Trout wrote:
> > I would love for files downloaded via a web browser or email client to
> > be marked as having come from the Internet. (Major bonus points if a
> > sync tool like nextcloud can keep files I generated labeled separate
> > from ones my coworkers made)
> > 
> > OS X web browsers do this, and when you try to open them the OS will
> > prompt "this came from the internet, do you want to open it". It looks
> > like its implemented with a few extended attributes. [1]
> 
> Windows too (implemented with NTFS alternate data streams).
> 
> > Do most of our file systems have extended attributes turned on by now?
> 
> I think (or at least hope) so.

Yes, xattrs are supported in most filesystems on Linux and our official
kernel packages enable them wherever they're an optional feature.

$ grep -rwl xattr_handler fs | grep -o '^fs/[^/]*/' | sort -u
fs/9p/
fs/afs/
fs/btrfs/
fs/ceph/
fs/cifs/
fs/ecryptfs/
fs/ext2/
fs/ext4/
fs/f2fs/
fs/fuse/
fs/gfs2/
fs/hfs/
fs/hfsplus/
fs/jffs2/
fs/jfs/
fs/kernfs/
fs/nfs/
fs/ocfs2/
fs/orangefs/
fs/overlayfs/
fs/reiserfs/
fs/squashfs/
fs/ubifs/
fs/xfs/

Ben.

-- 
Ben Hutchings
If the facts do not conform to your theory, they must be disposed of.

[toc] | [prev] | [next] | [standalone]

#9677

On Wed, 06 Dec 2017, Ben Hutchings wrote:
> > > Do most of our file systems have extended attributes turned on by now?
> > 
> > I think (or at least hope) so.
> 
> Yes, xattrs are supported in most filesystems on Linux and our official
> kernel packages enable them wherever they're an optional feature.
> 
> $ grep -rwl xattr_handler fs | grep -o '^fs/[^/]*/' | sort -u
> fs/9p/
> fs/afs/
> fs/btrfs/
> fs/ceph/
> fs/cifs/
> fs/ecryptfs/
> fs/ext2/
> fs/ext4/
> fs/f2fs/
> fs/fuse/
> fs/gfs2/
> fs/hfs/
> fs/hfsplus/
> fs/jffs2/
> fs/jfs/
> fs/kernfs/
> fs/nfs/
> fs/ocfs2/
> fs/orangefs/
> fs/overlayfs/
> fs/reiserfs/
> fs/squashfs/
> fs/ubifs/
> fs/xfs/

The most worrisome absence in that list being tmpfs :-(

-- 
  Henrique Holschuh

[toc] | [prev] | [next] | [standalone]

#9678

[Multipart message — attachments visible in raw view] — view raw

On Wed, 2017-12-06 at 21:33 -0200, Henrique de Moraes Holschuh wrote:
> On Wed, 06 Dec 2017, Ben Hutchings wrote:
> > > > Do most of our file systems have extended attributes turned on
> > > > by now?
> > > 
> > > I think (or at least hope) so.
> > 
> > Yes, xattrs are supported in most filesystems on Linux and our official
> > kernel packages enable them wherever they're an optional feature.
[...]
> The most worrisome absence in that list being tmpfs :-(

That's only because it lives in mm/shmem.c, not under fs/.  It does
support xattrs.

Ben.

-- 
Ben Hutchings
Beware of programmers who carry screwdrivers. - Leonard Brandwein

[toc] | [prev] | [next] | [standalone]

#9679

On Thu, Dec 07, 2017 at 12:09:22AM +0000, Ben Hutchings wrote:
>That's only because it lives in mm/shmem.c, not under fs/.  It does
>support xattrs.

Have you tried it?

Mike Stone

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | linux.debian.project

csiph-web