Re: [qubes-users] Debian Template APT Vulnerability - A ticking bomb?

2019-02-01 Thread 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.


On Fri, 1 Feb 2019 22:58:31 +
"'awokd' via qubes-users"  wrote:

>unman wrote on 2/1/19 4:05 PM:
>> On Mon, Jan 28, 2019 at 01:44:37PM +, 'awokd' via qubes-users wrote:  
>>> 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.  
>> 
>> 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.
>>   
>
>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!
>

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190201184123.3639af02%40gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Debian Template APT Vulnerability - A ticking bomb?

2019-02-01 Thread 'awokd' via qubes-users

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

On Mon, Jan 28, 2019 at 01:44:37PM +, 'awokd' via qubes-users wrote:

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.


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.



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!


--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/296d4c0d-9c3e-c26a-601d-fd16c8bde040%40danwin1210.me.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Debian Template APT Vulnerability - A ticking bomb?

2019-02-01 Thread unman
On Mon, Jan 28, 2019 at 01:44:37PM +, 'awokd' via qubes-users wrote:
> 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.

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.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190201160520.sngsqzec3ykz47mh%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Debian Template APT Vulnerability - A ticking bomb?

2019-02-01 Thread 'awokd' via qubes-users

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.



--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/ecbeb8ce-af33-fb63-4dc3-c4793b8ad273%40danwin1210.me.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Debian Template APT Vulnerability - A ticking bomb?

2019-01-29 Thread unman
On Mon, Jan 28, 2019 at 01:30:29PM -0800, goldsm...@riseup.net wrote:
> On 2019-01-28 19:46, billol...@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, billol...@gmail.com wrote:
> >> > On Sunday, January 27, 2019 at 12:22:03 PM UTC-5, unman wrote:

> 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.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190130002519.cyq5axyfci4mhad7%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Debian Template APT Vulnerability - A ticking bomb?

2019-01-28 Thread goldsmith
On 2019-01-28 19:46, billol...@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, billol...@gmail.com wrote:
>> > 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 .  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 

Re: [qubes-users] Debian Template APT Vulnerability - A ticking bomb?

2019-01-28 Thread billollib
On Monday, January 28, 2019 at 10:27:32 AM UTC-5, gold...@riseup.net wrote:
> On 2019-01-27 19:15, billol...@gmail.com wrote:
> > 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 .  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 

Re: [qubes-users] Debian Template APT Vulnerability - A ticking bomb?

2019-01-28 Thread goldsmith
On 2019-01-27 19:15, billol...@gmail.com wrote:
> 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 .  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 

Re: [qubes-users] Debian Template APT Vulnerability - A ticking bomb?

2019-01-27 Thread billollib
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 .  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

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe 

Re: [qubes-users] Debian Template APT Vulnerability - A ticking bomb?

2019-01-27 Thread unman
On Sun, Jan 27, 2019 at 02:37:16AM -0800, goldsm...@riseup.net wrote:
> On 2019-01-27 01:34, unman wrote:
> > On Sat, Jan 26, 2019 at 04:39:45AM -0800, goldsm...@riseup.net wrote:
> >>
> >> 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.
> > 
> > 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.
> 
> 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 

Re: [qubes-users] Debian Template APT Vulnerability - A ticking bomb?

2019-01-27 Thread Holger Levsen
On Sun, Jan 27, 2019 at 02:37:16AM -0800, goldsm...@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

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190127125649.khw72kcuj4yrw7al%40layer-acht.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature


Re: [qubes-users] Debian Template APT Vulnerability - A ticking bomb?

2019-01-27 Thread Achim Patzner
On 20190127 at 01:34 + 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


-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/6e557736131daa986892765e94eac2a6d25b9dec.camel%40noses.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Debian Template APT Vulnerability - A ticking bomb?

2019-01-27 Thread goldsmith
On 2019-01-27 01:34, unman wrote:
> On Sat, Jan 26, 2019 at 04:39:45AM -0800, goldsm...@riseup.net wrote:
>>
>> 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.
> 
> 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.

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 

Re: [qubes-users] Debian Template APT Vulnerability - A ticking bomb?

2019-01-27 Thread goldsmith
On 2019-01-27 01:34, unman wrote:
> On Sat, Jan 26, 2019 at 04:39:45AM -0800, goldsm...@riseup.net wrote:
>>
>> 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.
> 
> 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.
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 

Re: [qubes-users] Debian Template APT Vulnerability - A ticking bomb?

2019-01-26 Thread Andrew David Wong
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 26/01/2019 7.34 PM, unman wrote:
> On Sat, Jan 26, 2019 at 04:39:45AM -0800, goldsm...@riseup.net
> wrote:
>> 
>> 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.
> 
> 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.
> 

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

Re: [qubes-users] Debian Template APT Vulnerability - A ticking bomb?

2019-01-26 Thread unman
On Sat, Jan 26, 2019 at 04:39:45AM -0800, goldsm...@riseup.net wrote:
> 
> 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.

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.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190127013421.7pdxo4adq4tmqefe%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Debian Template APT Vulnerability - A ticking bomb?

2019-01-26 Thread Alexandre Belgrand
Le samedi 26 janvier 2019 à 04:39 -0800, goldsm...@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

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/4e0a5edcde58d2ce674a85bd67201f57f4dfc401.camel%40mailbox.org.
For more options, visit https://groups.google.com/d/optout.