Re: Automatic downloading of non-free software by stuff in main
> I guess you haven't read news about leaks happening once in a short while? > It seems as if in most cases the govt is interested mostly not in what was > leaked, but in who leaked it, so they can make an example of the > whistleblower. The arguments against this seem to center on an attacker being on your running and decrypted computer as the targeted user. There are bigger fires. Maybe this is worse for some theoretical leaker, but the fact a sensitive document was leaked is something that's easy to track down. Servers keep logs, too. I still don't understand why for the regular user, the URL you got a document from is worse than the ability for an attacker to read the document itself. I'm really having a hard time caring about an xattr specifying a URI where it was downloaded from being worse than an attacker being able to read the "sensitive" document off your drive. It's just not a threat model I can comprehend. Is this worse for a leaker? Maybe. So is the fact they print documents using their ID badges, or email reporters from their work email. I can't stop that. Everything you do on a computer leaves a trace. What's worse is normal users getting owned because macros run on a file they downloaded after having it emailed to them. I don't know that we can optimize an operating system for a leaker and expect sane behavior for our users. I *guess* it'd be a problem if a user downloaded something that had an API key in the URL? Sure, maybe that's not great. Other than that, I really can't imagine why reading the url attributes of the file is worse than reading the file itself. Out of the list of privacy concerns, this isn't even on my top 10 - out of my imagined steps to harden the OS against stupid attacks, this is in my top 10 :) Maybe someone can send a patch to LibreOffice to disable macros on documents with this set? That'd be a nice productive thing to come out of this thread :) Paul
Re: Automatic downloading of non-free software by stuff in main
On Thu, 2017-12-07 at 22:04 +0100, Adam Borowski wrote: > I might be inattentive, but I did not notice a single pro mentioned > on > this thread. The only part, Windows-like "you downloaded this file > from the > Internet, it may be bad" popup, can be done with a boolean, and is > still a > dubious idea. Pros: I periodically have to figure what former grad student have done for their computational experiments when they've left with nothing but access to their home directories. The source for where input data came from would be helpful. As a flag to indicate to automated processes, such as desktop indexers that should not blindly read a file. Cons: Metadata can be used against you. I personally would find the URL helpful when faced with trying to figure out where MyResults3.txt came from. Based on this discussion what I'd like to see: The XDG standard for where to store URL information, should also include a standard way to turn this feature on or off. Given issues with managing potentially hacked end users I would like it if toggling the state required administrator privileges. It should also be clearly defined in which situations the metadata should be removed. For instance it would be nice if copying the data between "my" computers via nextcloud or scp would preserve the attribute, but sending the file out via email or "untrusted" USB sticks would remove the attribute. That might be too hard, so a first milestone might be be moving or copying the file around the same file system should protected the attribute, and it should be stripped when the file is moved to a different file system. I don't know if xattrs can be locked to specific users, but it might also be reasonable that on multiuser systems an attribute like this should only be viewable by the owner & root. Diane
Re: Automatic downloading of non-free software by stuff in main
On Thu, Dec 07, 2017 at 12:17:10PM -0500, Paul R. Tagliamonte wrote: > If the Secret Police has seized your computer, has physical access to > your machine and the decryption passphrase for your system, I don't > think there's any website that you visited that would be more > incriminating than the rest of the drive. Some of us do take steps to be aware of potentially sensitive data on our disks. While for anything really dangerous you'd have an in-memory livecd, that's quite a hassle for everyday use, thus most of us don't go into paranoia and at most know how to wipe histories. This can be somewhat tricky as you have quasi-logs stored around, such as ~/.cache/thumbnails (timestamped!), but at least these are files that are reasonable for an average person to find. Smuggling this data in xattrs on the other hand? Even for those of us who mess with filesystem development and who are aware of caps (xattr -l /bin/ping) and thus rsync -X, it's surprising news. And usual tools shipped by current Debian don't mark the presence of such hidden data, nor do we install any xattrs aware tool by default. Now take an average somewhat technical user... no way to find this. But, I see you're dismissing possible harm as "theoretical". While I don't have real-life examples of bad xattrs yet, here's two related cases that happened to me, personally -- without bad consequences as both were on a desktop that doesn't leave my home, but it's obvious what would happen if the data was read by a bad guy, especially likely on an USB stick, laptop or phone that you travel past a border with. * upgrading to gnupg2 left a copy of my private key in ~/.gnupg/secring.gpg, despite me explicitly deleting it, and asking gpg to --list-secret-keys doesn't reveal that this "backup just in case you might want to downgrade" is still on the disk. * a sysadmin whom I have helped before asked me for help interpreting mail headers and some advice wrt something that happened at his company (I never had any relation with that company). Instead of sending a tarball, he copied the mails to a temporary IMAP account, to which I connected with Thunderbird. I've viewed a couple of the mails and promptly deleted the account. Yet Thunderbird not only downloads the entirety of data for offline use (this is kind of known), but also leaves data for deleted accounts on the disk, without any indication it's there (unless you dig into the profile's directory by hand). I found out these files are there only many years later. The mails included stuff that's illegal to distribute, and would clearly land the guy in jail, and possibly me as well. Semi-accidentally distributing them was a lapse of judgement on his part, but per the Dissident Test, I would really appreciate if software did not put its user in danger after the human error is noticed and (seemingly) rectified. > > (Your logic would argue that browser porn mode is basically > > pointless.) > > In a word of network taps, and a world where if I had a program > running on your computer without you knowing, yes, it is actually > literally useless. You probably noticed all the outrage against backdoors in Intel ME and AMD PSP. You might also want an operating system with open auditable code. > All it does it avoid storing data into your profile > or sending data the browser has about you, kinda. Not even that well, > just mostly well enough. It's not a security or privacy measure. I don't even use the "incognito mode", it's indeed nearly useless. It doesn't even block third-party trackers, block most means of fingerpriting, etc. You're much better off with a hand-crafted browser profile. Then, there's Tor, which is no magic bullet, but is a pretty powerful tool. > It does not make you safe. It doesn't avoid a network tap. Your > browser will still send an SNI before you handshake, and the Server's > Certificate, and your Client Certificate before the handshake is done. No need to even bother eavesdropping on SNI, browsers and most programs send a DNS query even for a domain you accessed a minute ago. Usually, this goes only over your ISP and the network path to an authoritative nameserver in the vicinity of the target server, but in some configurations it gets send to world's second most nosy company (with an enormous infrastructure for cross-matching such data!); despite that resolver being supposed to be anycasted, on at least one occassion I noticed it going to the US (the world's most nosy government (geoip-ing the AS doesn't work but you can look at traceroute). Even worse, if you use systemd-resolvd, any transient failure will silently use 8.8.8.8 for queries (#761658, wontfixed closed). Gee, guess how this goes if you're working for a company or country that the US finds "interesting". > The URL where you got a file is not nearly as privacy violating as the > file itself to the secret police. If you can read the attr, you can > read the f
Re: Automatic downloading of non-free software by stuff in main
> I don't know how does it work in reality but the Windows way to mark > downloaded files is actually to put a zone number into the attribute, > and > zones are that thing that theoretically distinguishes between local > sites, > internet sites, trusted sites etc.: > https://msdn.microsoft.com/en-us/library/ms537183.aspx > I'm not sure if anything really uses that. Found it. "Software Restriction Policies" can trigger off of 4 types of rules, one of which is Internet zone. https://technet.microsoft.com/en-us/library/cc786941(v=ws.10).aspx Being able to have Apparmor or SELinux rules that trigger off of user.xdg.origin.url values would be nice. Would that be a way to implement the "no non-free software rule" Ian Jackson originally asked for? A security policy that only allows opening executables from "free software" sources? (I see issues with recognizing firmware though, also that goal would probably be better served by not downloading the file in the first place.) As for origin.url, we still have a lot of work just defining when the attribute should be saved, when it should stay attached to copies, and when it should be stripped. Diane signature.asc Description: This is a digitally signed message part
Re: Automatic downloading of non-free software by stuff in main
On Thu, Dec 07, 2017 at 11:05:38AM -0800, Diane Trout wrote: > Tracker should have a way to avoid indexing files that have been > downloaded at least from untrusted domains, and possibly all downloaded > files. > > But yes, we should have a way of indicating "trusted" domains, so users > get fewer annoying popups. > > Bonus points if we could also have forbidden domains. Then your work VM > could trust your work servers, and your personal VM should know it > should refuse them. (At least that's a mistake I feel I'm likely to > make) Hehe. I don't know how does it work in reality but the Windows way to mark downloaded files is actually to put a zone number into the attribute, and zones are that thing that theoretically distinguishes between local sites, internet sites, trusted sites etc.: https://msdn.microsoft.com/en-us/library/ms537183.aspx I'm not sure if anything really uses that. -- WBR, wRAR signature.asc Description: PGP signature
Re: Automatic downloading of non-free software by stuff in main
On Thu, 2017-12-07 at 19:25 +0100, gregor herrmann wrote: > On Thu, 07 Dec 2017 08:16:47 -0500, Paul R. Tagliamonte wrote: > > > Restricting the execution of files one downloads or disabling > > macros on > > word documents you download and open would be a huge security win. > > I'm skeptical, at least if this leads to more of the > well-known-and-much-despised "Do you really want to …?" popups where > almost everyone just looks for the "Gee, yes, leave me alone, stupid > computer!" button. Ok. Here's a real vulnerability. Chrome auto-downloads files, GNOME tracker would then automatically index the downloaded file, and gstreamer has some decoders that implement some 8 bit CPUs that could be exploited. https://scarybeastsecurity.blogspot.com/2016/11/0day-poc-risky-design-d ecisions-in.html Tracker should have a way to avoid indexing files that have been downloaded at least from untrusted domains, and possibly all downloaded files. But yes, we should have a way of indicating "trusted" domains, so users get fewer annoying popups. Bonus points if we could also have forbidden domains. Then your work VM could trust your work servers, and your personal VM should know it should refuse them. (At least that's a mistake I feel I'm likely to make) Diane signature.asc Description: This is a digitally signed message part
Re: Automatic downloading of non-free software by stuff in main
> The pros vastly outweighs the speculitive cons on this, it's > literally > just a tag that's stored on the filesystem. If you can read the tag, > you can read the file. If you store porn that's readable by others, > it's not a shock that you go to porn websites. If you have an > overthrow the government file, it's not really that big of a deal > where you got it from. Chances are they'd be more interested in the > file. I agree. If the contents of the file are taboo, you need to protect the file. One obvious thing is a browser in incognito mode shouldn't be saving real data for the attribute. Though then I'd like to be able to disable incognito mode when in a managed computing environment. (Users accounts are regularly compromised, and so I have to assume some fraction of my users' accounts are actually controlled by hostile entities) Diane signature.asc Description: This is a digitally signed message part
Re: Automatic downloading of non-free software by stuff in main
On Thu, 07 Dec 2017 08:16:47 -0500, Paul R. Tagliamonte wrote:
> Restricting the execution of files one downloads or disabling macros on
> word documents you download and open would be a huge security win.
I'm skeptical, at least if this leads to more of the
well-known-and-much-despised "Do you really want to …?" popups where
almost everyone just looks for the "Gee, yes, leave me alone, stupid
computer!" button.
From my practical experience with inferior operating systems, I can
add that those warnings are often stupidly wrong ("My file server is
not the evil internet", "Yes I really sent this attachment to
myself", …), and in general usually I don't download files just to
fill my disk but in order to open and use them one way or another.
Cheers,
gregor
--
.''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org
: :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06
`. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
`- NP: Tanita Tikaram: Love Don't Need No Tyranny
signature.asc
Description: Digital Signature
Re: Automatic downloading of non-free software by stuff in main
On Thu, Dec 7, 2017 at 11:06 AM, Ian Jackson
wrote:
> Paul R. Tagliamonte writes ("Re: Automatic downloading of non-free software
> by stuff in main"):
>> I claim if you can read this attribute, you can observe the rest of those
>> actions passively.
>
> So the secret police who have seized my computer, or my spouse who
> suspects me of looking at the "wrong" sort of websites (but doesn't
> want to risk installing spyware), or my employer who has suspended me
> because they to fire me unjustifiably and is now searching my
> computer, can easily get into their time machine and go back and make
> the computer tell them what I did last week ?
>
> No.
If the Secret Police has seized your computer, has physical access to
your machine and the decryption passphrase for your system, I don't
think there's any website that you visited that would be more
incriminating than the rest of the drive.
> (Your logic would argue that browser porn mode is basically
> pointless.)
In a word of network taps, and a world where if I had a program
running on your computer without you knowing, yes, it is actually
literally useless. All it does it avoid storing data into your profile
or sending data the browser has about you, kinda. Not even that well,
just mostly well enough. It's not a security or privacy measure.
It does not make you safe. It doesn't avoid a network tap. Your
browser will still send an SNI before you handshake, and the Server's
Certificate, and your Client Certificate before the handshake is done.
The URL where you got a file is not nearly as privacy violating as the
file itself to the secret police. If you can read the attr, you can
read the file.
The pros vastly outweighs the speculitive cons on this, it's literally
just a tag that's stored on the filesystem. If you can read the tag,
you can read the file. If you store porn that's readable by others,
it's not a shock that you go to porn websites. If you have an
overthrow the government file, it's not really that big of a deal
where you got it from. Chances are they'd be more interested in the
file.
>
> Ian.
>
> --
> Ian JacksonThese 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.
--
:wq
Re: Automatic downloading of non-free software by stuff in main
Quoting Ian Jackson (2017-12-07 17:06:43)
> Paul R. Tagliamonte writes ("Re: Automatic downloading of non-free software
> by stuff in main"):
>> I claim if you can read this attribute, you can observe the rest of
>> those actions passively.
>
> So the secret police who have seized my computer, or my spouse who
> suspects me of looking at the "wrong" sort of websites (but doesn't
> want to risk installing spyware), or my employer who has suspended me
> because they to fire me unjustifiably and is now searching my
> computer, can easily get into their time machine and go back and make
> the computer tell them what I did last week ?
>
> No.
>
> (Your logic would argue that browser porn mode is basically
> pointless.)
Your "porn mode" browser plugin would tell your browser to pass a
redacted URL to the filesystem. Your enemies would then know only that
you redacted something.
If you want to hide that as well, you will need to replace your
"porn-mode" browser plugin with a "porn-and-stealth-mode plugin which
instead of simple redaction spews Facebook URLs instead.
(and you need also need to buy a faster laptop to keep up with the
CPU-hungry reasoning engine used to pick Facebook URLs adequately
non-random yet not themselves revealing - whatever that means...)
If you want to save power and money, then go deep into the config
options for your pron-mode plugin and enable "I trust everything on the
Internet and want to treat all downloaded files as local when in porn
mode".
- Jonas
--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
[x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: signature
technical terms (Re: Automatic downloading of non-free software by stuff in main)
Holger Levsen writes ("technical terms (Re: Automatic downloading of non-free
software by stuff in main)"):
> On Thu, Dec 07, 2017 at 04:06:43PM +, Ian Jackson wrote:
> > (Your logic would argue that browser porn mode is basically
> > pointless.)
>
> I didnt get what you ment originally, but after the 3rd mail using these
> words I realized you ment "privacy mode".
>
> I dont understand why you are using demeaning words for "privacy mode".
> Are you suggesting privacy=porn? I dont think so, so please use the
> proper words.
If you think "porn mode" is demeaning, I'm happy to call it "privacy
mode" instead. I don't think "porn mode" is demeaning; it's just what
my real-life social calls it.
Ian.
(who does a lot of hir browsing in privacy mode.)
--
Ian JacksonThese 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.
technical terms (Re: Automatic downloading of non-free software by stuff in main)
On Thu, Dec 07, 2017 at 04:06:43PM +, Ian Jackson wrote: > (Your logic would argue that browser porn mode is basically > pointless.) I didnt get what you ment originally, but after the 3rd mail using these words I realized you ment "privacy mode". I dont understand why you are using demeaning words for "privacy mode". Are you suggesting privacy=porn? I dont think so, so please use the proper words. Thanks. -- cheers, Holger signature.asc Description: PGP signature
Re: Automatic downloading of non-free software by stuff in main
Paul R. Tagliamonte writes ("Re: Automatic downloading of non-free software by
stuff in main"):
> I claim if you can read this attribute, you can observe the rest of those
> actions passively.
So the secret police who have seized my computer, or my spouse who
suspects me of looking at the "wrong" sort of websites (but doesn't
want to risk installing spyware), or my employer who has suspended me
because they to fire me unjustifiably and is now searching my
computer, can easily get into their time machine and go back and make
the computer tell them what I did last week ?
No.
(Your logic would argue that browser porn mode is basically
pointless.)
Ian.
--
Ian JacksonThese 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.
Re: Automatic downloading of non-free software by stuff in main
On Thu, Dec 07, 2017 at 01:59:16PM +, Holger Levsen wrote: > On Thu, Dec 07, 2017 at 01:52:07PM +, Ian Jackson wrote: > > Furthermore, this "file is dangerous" attribute ought to be copied > > much more. > > no, it ought to be the default. all files should be considered harmful, > unless tagged otherwise. All files _should_ be considered potentially harmful. Even if tagged safe. A previously-safe file might become harmful because it happens to trigger a newly found security bug. Possibly a newly found security bug that did not exist when the file was tagged safe. In my opinion, tagging files safe or harmful is not a winning strategy. I don't think it gives enough benefit to be worth it, and it doesn't seem to me it actually protects our users very much. An xattrs tag, in particular, gets lost so very easily, and having it applied inconsistently means there's a lot of ways in which any protection based on such a tag gets accidentally or intentionally circumvented. If we have a "this is safe" tag, instead of "this may be harmful", then that's also going to get lost often, leading to users getting annoyed by unintended security warnings all the time. Obviously it's possible to handle this by treating it as a by every time a file is copied without its xattr flag. But even from limited experience, that's going to be a very large number of bugs. If my security depends on all programs individually doing all the right things, I won't be feeling very secure. I don't have a good solution, but I suspect something like QubesOS may be the way forward. In other worse, isolate all processes into containers (or virtual machines) of some sort and arrange it so that this doesn't become too cumbersome to the user. (Disclaimer: I haven't had time to actually try QubesOS myself, yet.) The advantage of that approach is that the security gets centralised into fewer system components. It's less important that, say, Firefox is secure, if it can't be exploited to do bad things, if the container stops Firefox from deleting or modifying local files, or making unexpected network connections, or using too much RAM or CPU or other local resources. (I'm describing an ideal here, not the state of current technology.) -- I want to build worthwhile things that might last. --joeyh
Re: Automatic downloading of non-free software by stuff in main
On Dec 7, 2017 8:52 AM, "Ian Jackson"
wrote:
Paul R. Tagliamonte writes ("Re: Automatic downloading of non-free software
by stuff in main"):
> I hilariously discovered this last night as well (playing with IMA), and
> removing the creation of that attr would be a huge step back.
>
> Restricting the execution of files one downloads or disabling macros on
word
> documents you download and open would be a huge security win.
>
> These attributes are destroyed by merely coping the file, and are on
> the filesystem, not the file. It's not like sending a file via email
> leaks where I downloaded it from.
So if I use a browser in porn mode to download a file, and when I
close the browser the browser's record of the url where I got it is
deleted, but the url is saved in a hidden thing attached to the file.
Surely that is undesirable ?
And that's what happens if the browser implements this feature. If
the browser doesn't implement it (or suppresses it for porn mode
downloads), then I am vulnerable to the obvious clickbait attacks.
Furthermore, this "file is dangerous" attribute ought to be copied
much more. There are surely situations where that it is not copied
into copies of the file is a problem.
And, files can be dangerous if they came from emails, or file transfer
clients, as well as if they came from web pages. Some of these
sources might not have sensible URLs (and saving a dummy URL seems
wrong).
Finally, if a user thinks it useful to know where a file came from - I
can definitely see that this might be good (although personally I
think it should be disabled by default) - they might well want to do
that _and_ also mark the file as trusted for execution. That way if
they hear that the file is out of date they don't have to trust a
general search engine and re-navigate to the same url.
And, the privacy concerns mean that browser authors will properly
resist implementing it or enabling it by default.
I claim if you can read this attribute, you can observe the rest of those
actions passively.
Even putting a dummy value for incognito mode (a fake uri with a random
hash) would be fine, but I'm pretty OK with the current model. It makes my
time better spent doing forensics after I'm worried.
"Sticky" xattrs would be cool too, but alas, with imperfect primitives we
have an imperfect system.
It seems to me therefore that this XDG url saving attribute is not the
right shape to be reused as a boolean "file was downloaded from the
internet and might be dangerous" flag.
Ian.
Re: Automatic downloading of non-free software by stuff in main
On Thu, Dec 07, 2017 at 01:52:07PM +, Ian Jackson wrote: > Furthermore, this "file is dangerous" attribute ought to be copied > much more. no, it ought to be the default. all files should be considered harmful, unless tagged otherwise. > It seems to me therefore that this XDG url saving attribute is not the > right shape to be reused as a boolean "file was downloaded from the > internet and might be dangerous" flag. if the semantics were inverted, maybe. -- cheers, Holger signature.asc Description: PGP signature
Re: Automatically marking downloaded files (was Re: Automatic downloading of non-free software by stuff in main)
~Stuart Prescott writes ("Re: Automatically marking downloaded files (was Re:
Automatic downloading of non-free software by stuff in main)"):
> * wget in stretch doesn't set xattrs (but the version in sid does)
Cripes.
> * chromium doesn't set xattrs if you "File→Save" but does if the
> file type is downloaded.
>
> * I wasn't successful in doing this on a tmpfs - perhaps there are
> additional runes to add to the mount options that would make that possible.
Can we have a single place to enable/disable this behaviour ? I think
it should be disabled by default!
Ian.
--
Ian JacksonThese 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.
Re: Automatic downloading of non-free software by stuff in main
Paul R. Tagliamonte writes ("Re: Automatic downloading of non-free software by
stuff in main"):
> I hilariously discovered this last night as well (playing with IMA), and
> removing the creation of that attr would be a huge step back.
>
> Restricting the execution of files one downloads or disabling macros on word
> documents you download and open would be a huge security win.
>
> These attributes are destroyed by merely coping the file, and are on
> the filesystem, not the file. It's not like sending a file via email
> leaks where I downloaded it from.
So if I use a browser in porn mode to download a file, and when I
close the browser the browser's record of the url where I got it is
deleted, but the url is saved in a hidden thing attached to the file.
Surely that is undesirable ?
And that's what happens if the browser implements this feature. If
the browser doesn't implement it (or suppresses it for porn mode
downloads), then I am vulnerable to the obvious clickbait attacks.
Furthermore, this "file is dangerous" attribute ought to be copied
much more. There are surely situations where that it is not copied
into copies of the file is a problem.
And, files can be dangerous if they came from emails, or file transfer
clients, as well as if they came from web pages. Some of these
sources might not have sensible URLs (and saving a dummy URL seems
wrong).
Finally, if a user thinks it useful to know where a file came from - I
can definitely see that this might be good (although personally I
think it should be disabled by default) - they might well want to do
that _and_ also mark the file as trusted for execution. That way if
they hear that the file is out of date they don't have to trust a
general search engine and re-navigate to the same url.
And, the privacy concerns mean that browser authors will properly
resist implementing it or enabling it by default.
It seems to me therefore that this XDG url saving attribute is not the
right shape to be reused as a boolean "file was downloaded from the
internet and might be dangerous" flag.
Ian.
Re: Automatic downloading of non-free software by stuff in main
I hilariously discovered this last night as well (playing with IMA), and removing the creation of that attr would be a huge step back. Restricting the execution of files one downloads or disabling macros on word documents you download and open would be a huge security win. These attributes are destroyed by merely coping the file, and are on the filesystem, not the file. It's not like sending a file via email leaks where I downloaded it from. For most users, this attribute, if we start actually using it, would massively protect, not hurt their security. Paul On Dec 7, 2017 8:09 AM, "Holger Levsen" wrote: > On Thu, Dec 07, 2017 at 05:58:31PM +0500, Andrey Rahmatullin wrote: > > On Thu, Dec 07, 2017 at 12:50:06PM +, Holger Levsen wrote: > > > > > Ah, damnit. It supports *some* xattrs (like the security > namespace), > > > > > but apparently not *user* xattrs. > > > > Good. While xattrs have some uses, this is a hidden privacy hole > most users > > > > aren't aware of > > > > > > could you be so kind to explain that hidden hole? that would maybe help > > > with more people being aware… > > When you download a file, its original location is saved and can be > > retrieved. > > ah, so it's a privacy hole in certain tools, but not in xattr. > > how about filing bugs for those issues then? > > > -- > cheers, > Holger >
Re: Automatic downloading of non-free software by stuff in main
On Thu, Dec 7, 2017 at 9:09 PM, Holger Levsen wrote: > ah, so it's a privacy hole in certain tools, but not in xattr. Is it any more of a privacy hole than ~/.bash_history? -- bye, pabs https://wiki.debian.org/PaulWise
Re: Automatic downloading of non-free software by stuff in main
On Thu, Dec 07, 2017 at 05:58:31PM +0500, Andrey Rahmatullin wrote: > On Thu, Dec 07, 2017 at 12:50:06PM +, Holger Levsen wrote: > > > > Ah, damnit. It supports *some* xattrs (like the security namespace), > > > > but apparently not *user* xattrs. > > > Good. While xattrs have some uses, this is a hidden privacy hole most > > > users > > > aren't aware of > > > > could you be so kind to explain that hidden hole? that would maybe help > > with more people being aware… > When you download a file, its original location is saved and can be > retrieved. ah, so it's a privacy hole in certain tools, but not in xattr. how about filing bugs for those issues then? -- cheers, Holger signature.asc Description: PGP signature
Re: Automatic downloading of non-free software by stuff in main
On Thu, Dec 07, 2017 at 12:50:06PM +, Holger Levsen wrote: > > > Ah, damnit. It supports *some* xattrs (like the security namespace), > > > but apparently not *user* xattrs. > > Good. While xattrs have some uses, this is a hidden privacy hole most users > > aren't aware of > > could you be so kind to explain that hidden hole? that would maybe help > with more people being aware… When you download a file, its original location is saved and can be retrieved. -- WBR, wRAR signature.asc Description: PGP signature
Re: Automatic downloading of non-free software by stuff in main
On Thu, Dec 07, 2017 at 03:27:42AM +0100, Adam Borowski wrote: > > Ah, damnit. It supports *some* xattrs (like the security namespace), > > but apparently not *user* xattrs. > Good. While xattrs have some uses, this is a hidden privacy hole most users > aren't aware of could you be so kind to explain that hidden hole? that would maybe help with more people being aware… -- cheers, Holger signature.asc Description: PGP signature
Re: Automatic downloading of non-free software by stuff in main
> Which makes the XDG thing borderline, since the only indicator that a > file > has been downloaded they propose is the full url, not a boolean. But having the URL is useful. I would love to know where some terribly named file was downloaded from. (This is at least a fairly common problem in science) This would also be helpful for after the fact scans if an intrusion detection system discovered a site is hostile Shouldn't the url xattr be hidden if you're using an encrypted file system? What about just making it more obvious that a file has extended attributes? One of the problems with location data in images is many people didn't even know it was being captured. Could there be an color or flag for ls? and could nautilus & dolphin have some indicator? Diane
Re: Automatic downloading of non-free software by stuff in main
On Thu, Dec 07, 2017 at 11:53:50AM +0900, Mike Hommey wrote: > > Good. While xattrs have some uses, this is a hidden privacy hole most users > > aren't aware of (although /tmp/ is the filesystem least likely to be used > > forensically against you). > > Which makes the XDG thing borderline, since the only indicator that a file > has been downloaded they propose is the full url, not a boolean. Yup. Like OS X and unlike Windows. -- WBR, wRAR signature.asc Description: PGP signature
Re: Automatic downloading of non-free software by stuff in main
On Thu, Dec 07, 2017 at 03:27:42AM +0100, Adam Borowski wrote: > On Thu, Dec 07, 2017 at 01:33:41AM +, Ben Hutchings wrote: > > On Wed, 2017-12-06 at 19:14 -0500, Michael Stone wrote: > > > On Thu, Dec 07, 2017 at 12:09:22AM +, Ben Hutchings wrote: > > > > That's only because it lives in mm/shmem.c, not under fs/. It does > > > > support xattrs. > > > > > > Have you tried it? > > > > Ah, damnit. It supports *some* xattrs (like the security namespace), > > but apparently not *user* xattrs. > > Good. While xattrs have some uses, this is a hidden privacy hole most users > aren't aware of (although /tmp/ is the filesystem least likely to be used > forensically against you). Which makes the XDG thing borderline, since the only indicator that a file has been downloaded they propose is the full url, not a boolean. Mike
Re: Automatic downloading of non-free software by stuff in main
On Thu, Dec 07, 2017 at 01:33:41AM +, Ben Hutchings wrote: > On Wed, 2017-12-06 at 19:14 -0500, Michael Stone wrote: > > On Thu, Dec 07, 2017 at 12:09:22AM +, Ben Hutchings wrote: > > > That's only because it lives in mm/shmem.c, not under fs/. It does > > > support xattrs. > > > > Have you tried it? > > Ah, damnit. It supports *some* xattrs (like the security namespace), > but apparently not *user* xattrs. Good. While xattrs have some uses, this is a hidden privacy hole most users aren't aware of (although /tmp/ is the filesystem least likely to be used forensically against you). Looks like the only filesystems that allow disabling it via a mount option (nouser_xattr) are ext* and reiserfs, some more can do it via recompiling the kernel although this kills all xattrs, not just the user: namespace; most of these config options say "If unsure, say N." (other than CIFS, which is also the filesystem where your files are most likely to be readable by others) -- but they're all enabled in Debian kernels. [~]$ task add "patch btrfs for mount -o nouser_xattr" Meow! -- ⢀⣴⠾⠻⢶⣦⠀ 14:13 < icenowy[m]> are they hot enough? ;-) ⣾⠁⢰⠒⠀⣿⡁ 14:17 < icenowy[m]> I think now in Europe it should be winter? Let ⢿⡄⠘⠷⠚⠋⠀ the BPi warm you ;-) ⠈⠳⣄ 14:17 <@KotCzarny> yeah, i have a pc to warm me ;)
Re: Automatic downloading of non-free software by stuff in main
On Wed, 2017-12-06 at 19:14 -0500, Michael Stone wrote: > On Thu, Dec 07, 2017 at 12:09:22AM +, Ben Hutchings wrote: > > That's only because it lives in mm/shmem.c, not under fs/. It does > > support xattrs. > > Have you tried it? Ah, damnit. It supports *some* xattrs (like the security namespace), but apparently not *user* xattrs. Ben. -- Ben Hutchings Beware of programmers who carry screwdrivers. - Leonard Brandwein signature.asc Description: This is a digitally signed message part
Re: Automatically marking downloaded files (was Re: Automatic downloading of non-free software by stuff in main)
Anthony DeRobertis wrote: > On 12/05/2017 03:48 PM, 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) > > Chromium (by default), wget (by default), and curl (with --xattr) at > least already do this; they set the user.xdg.origin.url extended > attribute as documented at > https://www.freedesktop.org/wiki/CommonExtendedAttributes/ > > Firefox, unfortunately, does not do so yet, see > https://bugzilla.mozilla.org/show_bug.cgi?id=665531 TIL! For those playing along at home who are curious: # apt install xattr $ wget https://www.debian.org/ $ xattr -l index.html user.xdg.origin.url: https://www.debian.org/ Some notes: * wget in stretch doesn't set xattrs (but the version in sid does) * chromium doesn't set xattrs if you "File→Save" but does if the file type is downloaded. * I wasn't successful in doing this on a tmpfs - perhaps there are additional runes to add to the mount options that would make that possible. * getfattr from the attr package also works -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Re: Automatic downloading of non-free software by stuff in main
On Thu, Dec 07, 2017 at 12:09:22AM +, 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
Re: Automatic downloading of non-free software by stuff in main
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 signature.asc Description: This is a digitally signed message part
Re: Automatic downloading of non-free software by stuff in main
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
Re: Automatic downloading of non-free software by stuff in main
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. signature.asc Description: This is a digitally signed message part
Automatically marking downloaded files (was Re: Automatic downloading of non-free software by stuff in main)
On 12/05/2017 03:48 PM, 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) Chromium (by default), wget (by default), and curl (with --xattr) at least already do this; they set the user.xdg.origin.url extended attribute as documented at https://www.freedesktop.org/wiki/CommonExtendedAttributes/ Firefox, unfortunately, does not do so yet, see https://bugzilla.mozilla.org/show_bug.cgi?id=665531
Re: Automatic downloading of non-free software by stuff in main
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 signature.asc Description: PGP signature
Re: Automatic downloading of non-free software by stuff in main
On Thu, 2017-11-30 at 13:52 +, 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 signature.asc Description: This is a digitally signed message part
Re: Automatic downloading of non-free software by stuff in main
]] "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
Re: Automatic downloading of non-free software by stuff in main
On Fri, Dec 01, 2017 at 06:09:12AM +0100, Adam Borowski wrote: > On Thu, Nov 30, 2017 at 01:52:18PM +, 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 signature.asc Description: PGP signature
Re: Automatic downloading of non-free software by stuff in main
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)
Re: Automatic downloading of non-free software by stuff in main
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 signature.asc Description: PGP signature
Re: Automatic downloading of non-free software by stuff in main
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 signature.asc Description: PGP signature
Re: Automatic downloading of non-free software by stuff in main
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 JacksonThese 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.
Re: Automatic downloading of non-free software by stuff in main
On Fri, Dec 01, 2017 at 01:53:22PM +, 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 +, 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)
Re: Automatic downloading of non-free software by stuff in main
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 JacksonThese 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.
Re: Automatic downloading of non-free software by stuff in main
On Fri, Dec 01, 2017 at 04:10:46PM +, 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 signature.asc Description: PGP signature
Re: Automatic downloading of non-free software by stuff in main
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 JacksonThese 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.
Re: Automatic downloading of non-free software by stuff in main
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 signature.asc Description: PGP signature
Re: Automatic downloading of non-free software by stuff in main
On Fri, Dec 01, 2017 at 01:53:22PM +, 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 signature.asc Description: PGP signature
Re: Automatic downloading of non-free software by stuff in main
(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 +, 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.
Re: Automatic downloading of non-free software by stuff in main
On Thu, Nov 30, 2017 at 01:52:18PM +, 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.
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.
The biggest reason for me to avoid non-free code is that neither me nor
anyone among us can fix problems. And those derivatives you're talking
about tend to reintroduce this problem for political reasons (GFDL with
invariants).
Even Debian is not without fault here: for example, the ftpmasters accept
such a blatantly non-free licence as AGPL[1] into main.
> 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.
I don't think any such extra infrastructure is needed: what we have already
works well, at most it could take some clarification in the Policy. I
believe the model that's in place for apt is worth adopting for browsers,
media players and such.
That is:
* no new non-free code is ever installed without the user's consent
("new" defined at package granulation, allowing splits/etc)
* it's not even proposed unless the software detects that such non-free
parts are actually needed
* once a piece of non-free code is installed, it should receive updates
unless explicitly configured otherwise
The last part matters because of recent Chromium issues. Of course, checks
for updates should be done in a way that minimizes privacy issues (which
Chromium's upstream loves to maximize), but defaulting to no updates at all
is irresponsible.
Meow!
[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).
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.
You might read my words as a sort of FSF bashing, as both bad licenses are
provided by them (GFDL and AGPL3), but regular GPL is generally much better
than BSD/MIT: it emulates a world without copyright much better, as in such
a world we'd have decompilers, etc.
--
< darkling> When all you have is a hammock, every problem looks like a nap.
Re: Automatic downloading of non-free software by stuff in main
On Thu, Nov 30, 2017 at 01:52:18PM +, Ian Jackson wrote: > I would like to establish a way to prevent this. Why would the project do that, though? > (There are even whole Debian derivatives who have as one of their > primary goals, preventing this. Good. > 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.) Why? I also hope that you already have people who will do the actual work after the discussions will provide the architecture. -- WBR, wRAR signature.asc Description: PGP signature
