Debian Template APT Vulnerability - A ticking bomb?

[gold...@riseup.net]

Am I right in thinking that the recently discovered apt vulnerability
(DSA 4371-1) in Debian based systems could and should have been
mitigated against many years ago by downloading and activating an apt
package; "apt-transport-https", which forces apt updates via https? The
researcher (Max Justicz) who discovered the vulnerability has stated it
couldn't have been exploited if https had been implemented.

If "apt-transport-https" is the magic bullet, why in the past hasn't it
been implemented by default? And, why for the future, is it not being
implemented immediately by Qubes, Debian et al?

During the past decade many people with good foresight had predicted the
apt vulnerabilty and urged administrators to install the
solution;"apt-transport-https". Regrettably, the vocal majority of
so-called experts said that's unnecessary because the packages are
signed. Was that incompetent advice? or was it a coordinated response
from agents of State Actors to hide a deliberate backdoor? I've no idea,
but given Snowdens revelations I would not rule anything out.

[Alexandre Belgrand]

Le samedi 26 janvier 2019 à 04:39 -0800, gold...@riseup.net a écrit :
> If "apt-transport-https" is the magic bullet, why in the past hasn't
> it
> been implemented by default? And, why for the future, is it not being
> implemented immediately by Qubes, Debian et al?

Furtermore, very few Debian repos support https.
Here is the stanza to use https in Debian (adapt it for other flavors):

deb https://deb.debian.org/debian/ unstable main contrib non-free
deb-src https://deb.debian.org/debian/ unstable main contrib non-free

[unman]

No you're not right in thinking this.
You seem to have missed the section where Max explicitly say that "a
malicious mirror could still exploit a bug like this, even with https."
So apt-transport-https is no magic bullet, particularly as a cursory
glance suggests that it allows forcing SSL version to SSLv3, which is
known to be insecure.

Imagine that apt-transport-https *had* been adopted - have you actually
looked at the list of vulnerabilities in libcurl, and the various
breakages in the TLS CA system? I can imagine some one
posting exactly like you: "Was the move to https incompetent advice? or

was it a coordinated response from agents of State Actors to hide a
deliberate backdoor? I've no idea, but given Snowdens revelations I
would not rule anything out."

I would rule some things out. And in this case it looks like a simple
mistake. And if you read any of the arguments re http/https you'd see
that there are reasonable arguments on both sides, and the "so called
experts" took reasoned positions.

It's always been open to you to install the package and switch to https
transport in your Debian templates, of course. And Qubes had already
started to use that by default too.
Not to downplay the importance of the bug, but let's not lose
our heads.

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

In addition, from a Qubes perspective, it's worth reiterating this
part of the QSB:

| Normally, we do not release Qubes Security Bulletins (QSBs) to address
| vulnerabilities that only affect VMs internally without affecting the
| rest of the Qubes system, i.e. vulnerabilities that do not undermine
| the Qubes security model.
|
| For example, we do not release QSBs to address bugs in Firefox or
| Linux kernel USB stacks, because Qubes OS was designed under the
| primary assumption that in a typical desktop OS there will be
| countless such bugs and that humankind will never be able to patch all
| of them promptly (at least not as quickly as developers introduce new
| bugs). This is, in fact, the very reason we designed Qubes OS as an
| implementation of the security-by-compartmentalization approach.

Whenever we're tempted to ask, "Why didn't Qubes secure X inside of a
domU?" we should remember this. Not only is it unrealistic to expect
the small Qubes team to fix vulnerabilities in software that many
larger teams have failed to fix; it also misses the whole point of
Qubes in the first place, which is to accept that such vulnerabilities
are inevitable and protect ourselves from them by compartmentalizing
them, limiting the damage they can do.

[I can imagine a cynic responding, "Then why did you issue a QSB at
all?" Even though there was no failure in the Qubes security model
here (in fact, it did exactly what it was supposed to by limiting the
damage this bug could do), we care far more about keeping users safe
than about the "optics" of issuing a QSB. We would rather let some
people misinterpret the situation and mistakenly think that this shows
some flaw in Qubes if it means getting the word out so our users can
secure their systems as quickly as possible.]

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlxNHwUACgkQ203TvDlQ
MDBzvhAAwRQ6ZjTY/dznI3o9fsR9ZSiv0gaCwZYRDqNwoUvXQqKlnqOLhV4Z8WuN
8F3Jcd812AcRIFmsmCXDiFQIW7SF59ywmtwRTukbpuVty+ZdxbIq5zo9WriZH93k
1P/91onvoCrtGI2CgTR8yb0PRF3xBhsKHwmFkKj4Kq1ablM2l1UYlN3VZ6GjxLlc
TyXus26LChVm48jcoOB3PTMKpWw91LbTQPebl3OlwhpsilCWKSw0ge3MylLMFJLr
q2MGmUxCtpJQTaoyMEAAReEEiV/UaytTJikDQcQ3YjiaCVqxodYqD5/dUfD5lFLp
+o7a6wb//eHtwCMQG+RWWIlLaxNlPsUxT2BvujVmNeOn+e1z+jdktRxXK/Vknq8d
a/eYui5SJdsVHQQAgkJgYPLaGFQqXg+2u+O8pgwZSoYXu63w7r2YCIB77LBmXumF
1u0JKMeX5NeP+1NyFPa4ELPiq07d+5FxEP47kzMpn83BFfQlPaQbur64st68iYbX
wQFMX3Ro1kq/fMVTyH6gaIHmWNxjwrV5bcL5vTjessKKJScOFZigwK8ecHcGcbp5
nxo/l4Iy/ImsgvhT6XKDKWCk4QgrmGpM/XFfXLLx5m1T2hbz6iAvcMihOom85sOF
oiAO+cowbZjYiYS+TxEgnVCTw1Ju086Fz9A72A/H4X7Y7RuHV8Y=
=oKXP
-----END PGP SIGNATURE-----

[gold...@riseup.net]

Thank you for your responses.
I appear to have prodded a hornets nest! I make no apology for that.
It’s good and allows everyone an opportunity to express their views.
Hopefully backed up by facts.
Here's some background as to where I'm coming from:
1/ I use Debian based templates; including Whonix, exclusively (I do
have doubts about Fedora’s integrity; calls home, owned by IBM/Redhat,
monetised etc). So, all my apps (including service apps like
sys-firewall, sys-net sys-usb) are compromised if Debian gets exploited.
At this point for me its game over. I'm completely stuffed. Now when
Qubes eventually issues a QSB; Security Bulletin almost 24 hrs after the
vulnerability was publicly announced, saying its comparable to a firefox
exploit: I get angry and say what complete and utter PR horsesh*t.

2/ Nobody's going to blame Qubes for an vulnerability like this in
Debian etc. However, the least I'd expect from Qubes is a timely
warning. Personally, I got a warning from Whonix a good 12 hrs before
Qubes alerted us!

3/ Most people have made an assumption that the good guys i.e. Max
Justicz found the vulnerability first. Personally I never assume
anything and prefer to think "worst case scenario". In this case I have
had no privacy or security whatsoever for possibly years. Whilst Dom0's
been protected, I'm not - what use is that?

Now turning to Unman's comments:
1/ no you're not right in thinking this.
you seem to have missed the section where max explicitly say that "a

malicious mirror could still exploit a bug like this, even with https."

so apt-transport-https is no magic bullet, particularly as a cursory
glance suggests that it allows forcing ssl version to sslv3, which is
known to be insecure.
With respect Unman, you seem to have missed the section where Max
explicitly says "Supporting http is fine. I just think it’s worth making
https repositories the default the safer default and allowing users to
downgrade their security at a later time if they choose to do so".

Furthermore, The Guardian Project have been promoting the use of https
for apt package retrieval for many years. Here's their latest statement;
"There is a new vulnerability in Debian’s apt that allows anything that
can Man-in-the-Middle (MITM) your traffic to get root on your
Debian/Ubuntu/etc boxes. Using encrypted connections for downloading
updates, like HTTPS or Tor Onion Services, reduces this vulnerability to
requiring root on the mirror server in order to exploit it. That is a
drastic reduction in exposure. We have been pushing for this since
2014".
https://guardianproject.info/2019/01/23/use-onions-https-for-software-updates/

2/ Imagine that apt-transport-https *had* been adopted - have you
actually
looked at the list of vulnerabilities in libcurlnd the various

breakages in the TLS CA system?

You appear to be saying that Debian have created a package;
apt-transport-https which is not fit for purpose? Have you notifified
them of this? and if so what was their response?

3/It's always been open to you to install the package and switch to

https
transport in your Debian templates, of course. And Qubes had already
started to use that by default too.
Not to downplay the importance of the bug, but let's not lose
our heads.

Most users like me would have had no inkling that the https option
existed. Is that option, with its pros and cons explained, located
anywhere in the qubes docs; Ive searched and can't find it.
No one as far as I can tell is losing their heads. We're simply looking
for a system that has a philosophy incorporating; "defence in depth" and
continuous improvement. And, for the most part, Qubes delivers on that.

Lets keep an open mind on these issues and not become entrenched in
intractable positions.

[gold...@riseup.net]

On 2019-01-27 01:34, unman wrote:

Apologies. I've reposted this because the subscripts weren't clear in
the earlier post. Hopefully this will be clearer.

Thank you for your responses.
I appear to have prodded a hornets nest! I make no apology for that.
It’s good and allows everyone an opportunity to express their views.
Hopefully backed up by facts.
Here's some background as to where I'm coming from:
1/ I use Debian based templates; including Whonix, exclusively (I do
have doubts about Fedora’s integrity; calls home, owned by IBM/Redhat,
monetised etc). So, all my apps (including service apps like
sys-firewall, sys-net sys-usb) are compromised if Debian gets exploited.
At this point for me its game over. I'm completely stuffed. Now when
Qubes eventually issues a QSB; Security Bulletin almost 24 hrs after the
vulnerability was publicly announced, saying its comparable to a firefox
exploit: I get angry and say what complete and utter PR horsesh*t.

2/ Nobody's going to blame Qubes for an vulnerability like this in
Debian etc. However, the least I'd expect from Qubes is a timely
warning. Personally, I got a warning from Whonix a good 12 hrs before
Qubes alerted us!

3/ Most people have made an assumption that the good guys i.e. Max
Justicz found the vulnerability first. Personally I never assume
anything and prefer to think "worst case scenario". In this case I have
had no privacy or security whatsoever for possibly years. Whilst Dom0's
been protected, I'm not - what use is that?

Now turning to Unman's comments:
1/

no you're not right in thinking this.
you seem to have missed the section where max explicitly say that "a

malicious mirror could still exploit a bug like this, even with https."

so apt-transport-https is no magic bullet, particularly as a cursory
glance suggests that it allows forcing ssl version to sslv3, which is
known to be insecure.

With respect Unman, you seem to have missed the section where Max
explicitly says "Supporting http is fine. I just think it’s worth making
https repositories the default the safer default and allowing users to
downgrade their security at a later time if they choose to do so".

Furthermore, The Guardian Project have been promoting the use of https
for apt package retrieval for many years. Here's their latest statement;
"There is a new vulnerability in Debian’s apt that allows anything that
can Man-in-the-Middle (MITM) your traffic to get root on your
Debian/Ubuntu/etc boxes. Using encrypted connections for downloading
updates, like HTTPS or Tor Onion Services, reduces this vulnerability to
requiring root on the mirror server in order to exploit it. That is a
drastic reduction in exposure. We have been pushing for this since
2014".
https://guardianproject.info/2019/01/23/use-onions-https-for-software-updates/

2/

Imagine that apt-transport-https *had* been adopted - have you actually

looked at the list of vulnerabilities in libcurlnd the various

breakages in the TLS CA system?

You appear to be saying that Debian have created a package;
apt-transport-https which is not fit for purpose? Have you notifified
them of this? and if so what was their response?

3/

It's always been open to you to install the package and switch to https
transport in your Debian templates, of course. And Qubes had already
started to use that by default too.
Not to downplay the importance of the bug, but let's not lose
our heads.

[Achim Patzner]

On 20190127 at 01:34 +0000 unman wrote:
> I would rule some things out. And in this case it looks like a simple
> mistake.

It could even be intention. Most of you do not think about the cost
associated with TLS (and growing with key lengths). But there always
were (and will be) discussions whether offering a certain service
(especially free of charge) will be worth it considering the attached
cost. We're lucky that technology stepped up a bit (I remember doing
performance analysis when SSL was pushed into the market by Netscape
and found out that it cost about an eightfold increase in CPU
resources); you might want to read
https://blog.cloudflare.com/how-expensive-is-crypto-anyway/ to get a
more recent look at things. But with Quantum computers just around the
corner there will be a new arms race current CPUs are not prepared for.
And keep in mind that only protecting "important targets" is stupid; if
you do not encrypt everything you are attaching target markers to your
secrets.

Crypto is added cost and designers will always try to find a balance
between cost and security...


Achim

[Holger Levsen]

On Sun, Jan 27, 2019 at 02:37:16AM -0800, gold...@riseup.net wrote:
> > 2/
> > Imagine that apt-transport-https *had* been adopted - have you actually
> > looked at the list of vulnerabilities in libcurlnd the various
> > breakages in the TLS CA system?

that. plus, apt is running as root and apt-transport-https needs to
parse untrusted input...

> You appear to be saying that Debian have created a package;
> apt-transport-https which is not fit for purpose? Have you notifified
> them of this? and if so what was their response?

one of the reasons Debian has not made apt-transport-https is that there
is a trade-off between gaining some security properties by using https
and loosing some (see above in this very mail)...

what really would need to be done would be to rewrite/patch apt, to do all the
certificate verification as less priviledged user. I *believe* modern apt
suports this (at least I have an _apt user in my /etc/passwd on stretch
systems, but not on jessie), but I'm not sure (read: i have no idea)
whether apt-transport-https uses that too.


--
tschüß,
Holger

-------------------------------------------------------------------------------
holger@(debian|reproducible-builds|layer-acht).org
PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

[unman]

On Sun, Jan 27, 2019 at 02:37:16AM -0800, gold...@riseup.net wrote:

It's very late, so I wont be ale to give your post the attention it
deserves, so apologies for that. Also, it's easier for me just now
not to reply inline - again,apologies. Everything I say here is my
personal opinion.

1. You're completely right. If Debian is exploited then all your
templates
may be compromised, and therefore all your qubes may be.No doubt.
(You should probably be considering your service qubes compromised as
a matter of course.) The QSB did not compare it to a firefox exploit:
indeed it explicitly contrasted this with a Firefox exploit, and
explained
why it was different, and why it merited a QSB. If you reread the QSB
you may find that you git angry a little too quickly.

2. I completely agree about the tardiness of the Qubes advisory, and
have already raised this as an issue. BUT, if security is an issue for
you , you should be reviewing the security advisories for Xen, Debian,
Fedora , (and whatever key software you use), as a matter of course.
Qubes does not pretend to offer an all in one solution, and it does not
take the onus off the user to keep themselves protected.

3. I completely agree with you that it's a mistake to assume that there
wasn't a 0-day circulating for this, although I haven't found any
evidence that there was. It *is* possible that the vulnerability has
been know and exploited for years. No doubt.

I wont comment on the first of your replies to me. Doesn't seem
fruitful.

5. Yes, I have discussed the shortcomings of that implementation, and
work has been done to integrate https in to apt directly. I note that
you haven't commented on the main issue - that https is not a magic
bullet, and that switching to it would bring its own vulnerabilities.

6. Many users seem to think that Qubes provides a complete solution to
security or privacy. It doesn't.
Using Qubes does not take away the obligation on users to make sure that
their templates and software are configured and updated to as secure a
position as possible. Users should review the choices made by Qubes,
and make sure that they are consistent with their needs. (You have done
this by selecting all Debian templates.)
For example, some users do not like passwordless root,
and there are mechanisms to remove this.
It's not feasible for Qubes to duplicate information provided for Xen,
Fedora, Debian, Arch, and any other templates that people use. As I've
said, if security is an issue for you then you should be keeping up
to date with security bulletins from those sources, and any other key
software that you use. That seems obvious to me. I don't think it's
anywhere in the docs.
Qubes provides a framework for using software - it doesn't take away the
onus on users to use that software properly, and to ensure they are aware
of good practice. (As an aside I'm always baffled by people querying
how they can use Facebook under Tor or Whonix. What are they thinking?)
I regularly audit templates with tripwire, running from an
offline openBSD qube, and do standards checks with debsums. I do good
deal of my work offline in openBSD and then transfer encrypted in to
other qubes for transmission. That seems like overkill, and isn't for
everyone: it might be for you.

unman

[bill...@gmail.com]

On Sunday, January 27, 2019 at 12:22:03 PM UTC-5, unman wrote:
>[snip]

> Qubes provides a framework for using software - it doesn't take away the
> onus on users to use that software properly, and to ensure they are aware
> of good practice. (As an aside I'm always baffled by people querying
> how they can use Facebook under Tor or Whonix. What are they thinking?)
> I regularly audit templates with tripwire, running from an
> offline openBSD qube, and do standards checks with debsums. I do good
> deal of my work offline in openBSD and then transfer encrypted in to
> other qubes for transmission. That seems like overkill, and isn't for
> everyone: it might be for you.
>
> unman

I think this is the most important thing you wrote. I used to do network security for a small scientific government network back in the 1990s, and I constantly ran into the problem that there is an inverse relationship between security and usability. The scientists on my network were constantly finding ways of going around whatever security measures I put in place precisely because they didn't want to deal with the "hassle."

But I'm no different, really. Not too many years ago, I routinely disabled SELinux when I installed a new OS simply because I considered it too much of a hassle to learn how to use it effectively. It made it difficult for me to do stuff. Everybody yelled at me, but it just wasn't worth the effort to me. Now, I've learned it a bit and it's not such a hassle.

There's this balance between the inconvenience/damage associated with an intrusion versus the inconvenience associated with the security configuration. For me on the computer I'm using as I write this, it wouldn't be the end of the world if *everything* on my computer were owned by someone else. It would be a hassle, but not fatal -- I have insurance, etc. for the financial information I have here, and I don't really care if someone sees the email conversations I have on this machine.

So, considering the financial stuff, for instance. There's a hassle with someone getting my credit card information. It's happened (though not because of a computer glitch). My card gets frozen, I can't use it for a week or two, I have to make a bunch of phone calls, etc. But I'm financially protected and eventually I'll be fine. The problem is the hassle factor, not financial ruin. My biggest security concern is someone using up all my bandwidth; I live in a rural area and have metered service. Someone using up 5 gigs of bandwith is more concerning to me than them owning 5 gigs of data from my machine. So, I have to ask myself, which is more hassle -- dealing with the intrusion, or dealing with the security hassle?

It's my responsibility to determine where that balance is, and nobody else's. And it's likely different for everybody. For instance, I used to have a blog, but I'm a litigation consultant and I started seeing my blog posts turning up in court. So I don't blog any more. I can't be on Facebook, or LinkedIn, or Doximity, or ResearchGate. That's not a problem for me, but it would drive my wife crazy. I use one laptop for some stuff, and I use a different laptop, differently configured, for other stuff.

And, the higher up the food chain you go with respect to people interested in surveilling you, the less chance you have of keeping them out. I'm out of the business now, but back in the day I occasionally did some classified work. I remember some years ago, I called a friend of mine who worked for the government. I called him using the work phone of an acquaintance to ask him a technical question. He picked up the phone and immediately said "Hey, Bill, how you doing?"

I was stunned. I asked him how the hell he knew it was me. He said "Bill, I'm with the <government agency>. We always know where you are."

I have another friend who spent his early career working for a government contractor. His job was to break into people's houses at night and install keyloggers on their computers. With a subpoena, of course. All the security software in the world won't help you with that.

The key, for me, is to achieve the maximum security that I can achieve and stay below my maximum hassle tolerance. Qubes is nice because it adds a big uptick in transparent security with only a small uptick in hassle -- at least for someone who is fairly conversant with sysadmin stuff. So for me it's a big win. But it's not all there is.

There's no such thing as perfect security. There's only finding the balance between one's perceived risk, one's actual vulnerability, and one's tolerance for hassle. And any security configuration is self-defeating if:

1) People take it for granted and think that it's all they have to think about, and/or
2) It's enough of a hassle that you start going around it to do your work.

billo

[gold...@riseup.net]

To Billollib.

To sumarise your post; 1/ It's the Users of software that subvert OS's
and/or Software. 2/ I've nothing to hide so why bother.
Both topics are, I feel, are hijacking this post; which concerns the Apt
vulnerability within Debian. That's not to say your points aren't
important, they are. And, for that reason I'll provide a response.
Which is based largely on the opinions of recognised experts in thier
fields:

1/ Users are to blame. It's that classic argument put forward by a
minority of software developers; I've created a wonderful system and its
the users who subverted it. We've seen this approach from the likes of
Mr Zuckerburg who blames the users of Facebook for allowing their
privacy to be invaded. In reality of course his software is carefully
crafted to covertly exploit users privacy and then maximise revenue
streams by covertly selling their data to advertisers and politcal
lobbyists; e.g. Cambridge Analyitica. I and many others believe that
Twitter, Microsoft, Apple et al operate similar business models based on
stealing data and up-selling it. Of course when a data breach is made
public their highly paid "spin doctors" will invariably concoct are
yarn; blaming users or anyone else they can think of and then send it to
their buddies in main stream media for publication.

2/ I've nothing to hide so why bother. It's this submissive, cavalier
and defeatist approach to online privacy that's regularly promoted, in
the form of propaganda by virtually all main stream media outlets on
behalf of their owners; a small clan of very rich "global elites"; who
attempt and largely succeed in exerting control and influence over the
masses; i.e. us peasants.

I think the most appropriate and succinct reply I've seen is: "If you
think privacy is unimportant for you because you have nothing to hide,
you might as well say free speech is unimportant for you because you
have nothing useful to say".

You might also wish to read this in depth response:
https://www.aclu.org/blog/national-security/secrecy/you-may-have-nothing-hide-you-still-have-something-fear.

Last but certainly not least, Here's a quote from that renowned privacy
supporting journalist Glynn Greenwald; the guy who broke the Ed Snowden
revelations. "Over the last 16 months, as I've debated this issue around
the world, every single time somebody has said to me, "I don't really
worry about invasions of privacy because I don't have anything to hide."
I always say the same thing to them. I get out a pen, I write down my
email address. I say, "Here's my email address. What I want you to do
when you get home is email me the passwords to all of your email
accounts, not just the nice, respectable work one in your name, but all
of them, because I want to be able to just troll through what it is
you're doing online, read what I want to read and publish whatever I
find interesting. After all, if you're not a bad person, if you're doing
nothing wrong, you should have nothing to hide." Not a single person has
taken me up on that offer". By: Glenn Greenwald in Why privacy matters -
TED Talk

[bill...@gmail.com]

Your summary is incorrect, and you do my a disservice by misstating what I wrote and then arguing against your misstatements.

I did not say "I don't have anything to hide." What I wrote, if you reread it carefully, is that I modulate my security demands according to the balance of useability and security. You will note that I said that I use multiple computers, each with different security configurations. The stuff I "have to hide" I put on a different computer than this one.

It may be your choice to put all your eggs in one basket. I do not. That doesn't mean my position is that "I don't have anything to hide." What I do is I recognize that any outward facing box is a threat. Any outward facing box that you use to surf the web, try out new software, and generally play around with is a greater threat. What I wrote was that I don't put my crown jewels on the box that it likely to get compromised. That is *very* different that saying "I don't have anything to hide" or "I don't need security."

So you don't need to lecture me on whether or not I need security. You need to realize that all threats are not the same, and all security requirements for all places are not the same. That's why security is different when you enter your average grocery store vs your average courthouse vs your average military base vs the FBI headquarters vs Langley. And my security requirements are different for this machine than they are for the machine, for instance, that I keep medical or legal information on, or my Android phone. I don't do things using my smartphone that I don't want someone surveilling. It's not that "I don't have anything to hide, so why bother." It's "I know there's nothing I can do to make it secure, so I won't do things on it that I don't want surveilled."

And I'm not "blaming" anybody. What I'm saying is that ultimately every person has responsibility for their own security. And if you don't believe that, you will never *have* good security, because you will always be standing in the ashes of your privacy complaining that someone else didn't take care of it for you.

[gold...@riseup.net]

To Billollib

First, Its disappointing you didn't apologise for hijacking my thread.

Second, you complain I misrepresented you in my summary. Perhaps you
forget writing the following: " I used to do

> > network security for a small scientific government network back in the
> > 1990s, and I constantly ran into the problem that there is an inverse
> > relationship between security and usability. The scientists on my
> > network were constantly finding ways of going around whatever security
> > measures I put in place precisely because they didn't want to deal
> > with the "hassle."

My summary of the above was: "It's the Users of software that subvert
OS's.....". I think that's a fair summary of what you said about Users -
in this case scientists.

Finally: Please, no further hijacking of other peoples posts

[unman]

On Mon, Jan 28, 2019 at 01:30:29PM -0800, gold...@riseup.net wrote:
> On 2019-01-28 19:46, bill...@gmail.com wrote:
> > On Monday, January 28, 2019 at 10:27:32 AM UTC-5, gold...@riseup.net wrote:
> >> On 2019-01-27 19:15, bill...@gmail.com wrote:
> >> > On Sunday, January 27, 2019 at 12:22:03 PM UTC-5, unman wrote:
<snip>

> To Billollib
>
> First, Its disappointing you didn't apologise for hijacking my thread.
>
> Second, you complain I misrepresented you in my summary. Perhaps you
> forget writing the following: " I used to do
> > > network security for a small scientific government network back in the
> > > 1990s, and I constantly ran into the problem that there is an inverse
> > > relationship between security and usability. The scientists on my
> > > network were constantly finding ways of going around whatever security
> > > measures I put in place precisely because they didn't want to deal
> > > with the "hassle."
> My summary of the above was: "It's the Users of software that subvert
> OS's.....". I think that's a fair summary of what you said about Users -
> in this case scientists.
>
> Finally: Please, no further hijacking of other peoples posts
>

To state the obvious it's not your thread, and no one need apologise for
commenting, or taking the discussion in a new direction.
I doubt that Billollib "forgot writing" anything. I assume that he felt
that you represented him, and you had missed the point of what he wrote.
Let's try to be civil please.

[awokd]

unman wrote on 1/27/19 5:21 PM:

> (As an aside I'm always baffled by people querying
> how they can use Facebook under Tor or Whonix. What are they thinking?)

There are good reasons for it. See
https://www.wired.com/2014/10/facebook-tor-dark-site/ for example. To
the thread's topic, using Debian's onion repositories helps avoid MITM
attacks. Of course, can't protect against compromise of the repositories
themselves, but that's not a problem that can be solved at the
communications layer.

[unman]

You missed my point because I wasn't clear enough.
I know that Facebook is accessible over Tor.
But why would anyone concerned with privacy ,(presumably why they are
using Tor or Whonix), want to sup with the devil of Facebook? I don't
think any spoon is long enough, not even one passing through 3 hops.

[awokd]

unman wrote on 2/1/19 4:05 PM:

Understood. I'm picturing a pseudonymous female blogger who wants to
organize in a country where they aren't allowed to use the internet. Not
sure how compatible that noble goal is with Facebook's real name policy.
A more trite example would be a normal Facebook user who doesn't
necessarily want them and all their 3rd party advertisers to know from
what location/IP address he's logging in. However, I've never had the
desire to create a Facebook account either!

[Stuart Perkins]

I have a couple. One I use a lot, loaded with disinformation. Two are even less complete, but rarely used.

I lost access to a fourth by accidentally trying to login over tor, and it insisted on ID to unlock it...so I just ignore that one now.