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

Groups > linux.debian.user > #257215 > unrolled thread

Apt sources.list

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

Contents

  Apt sources.list <paulf@quillandmouse.com> - 2023-04-15 14:20 +0200
    Re: Apt sources.list Brian <ad44@cityscape.co.uk> - 2023-04-15 14:30 +0200
      Re: Apt sources.list Greg Wooledge <greg@wooledge.org> - 2023-04-15 15:00 +0200
        Re: Apt sources.list Alain D D Williams <addw@phcomp.co.uk> - 2023-04-15 15:40 +0200
          Re: Apt sources.list <tomas@tuxteam.de> - 2023-04-15 15:50 +0200
            Re: Apt sources.list Alain D D Williams <addw@phcomp.co.uk> - 2023-04-15 16:10 +0200
              Re: Apt sources.list <tomas@tuxteam.de> - 2023-04-15 16:20 +0200
          Re: Apt sources.list Brian <ad44@cityscape.co.uk> - 2023-04-15 16:10 +0200
          Re: Apt sources.list Charles Curley <charlescurley@charlescurley.com> - 2023-04-15 16:50 +0200
          Re: Apt sources.list <paulf@quillandmouse.com> - 2023-04-15 17:10 +0200
            Re: Apt sources.list Dan Ritter <dsr@randomstring.org> - 2023-04-15 18:40 +0200
              Re: Apt sources.list <tomas@tuxteam.de> - 2023-04-15 19:50 +0200
                Re: Apt sources.list davidson <davidson@freevolt.org> - 2023-04-16 01:00 +0200
                  Re: Apt sources.list Greg Wooledge <greg@wooledge.org> - 2023-04-16 01:20 +0200
                    Re: Apt sources.list The Wanderer <wanderer@fastmail.fm> - 2023-04-16 01:30 +0200
                      Re: Apt sources.list Stefan Monnier <monnier@iro.umontreal.ca> - 2023-04-16 02:30 +0200
                    Re: Apt sources.list davidson <davidson@freevolt.org> - 2023-04-16 02:20 +0200
                    Re: Apt sources.list Tim Woodall <debianuser@woodall.me.uk> - 2023-04-16 21:10 +0200
                      Re: Apt sources.list Jeffrey Walton <noloader@gmail.com> - 2023-04-16 23:00 +0200
                        Re: Apt sources.list Jeffrey Walton <noloader@gmail.com> - 2023-04-17 03:30 +0200
                          Re: Apt sources.list <tomas@tuxteam.de> - 2023-04-17 06:50 +0200
                            Re: Apt sources.list Jeffrey Walton <noloader@gmail.com> - 2023-04-17 17:10 +0200
                  Re: Apt sources.list <tomas@tuxteam.de> - 2023-04-16 07:40 +0200
                  Re: Apt sources.list Eduardo M KALINOWSKI <eduardo@kalinowski.com.br> - 2023-04-16 14:10 +0200
            Re: Apt sources.list Alain D D Williams <addw@phcomp.co.uk> - 2023-04-15 20:30 +0200
              Re: Apt sources.list Brian <ad44@cityscape.co.uk> - 2023-04-15 20:40 +0200
              Re: Apt sources.list Andy Smith <andy@strugglers.net> - 2023-04-15 22:00 +0200
            Re: Apt sources.list Charles Curley <charlescurley@charlescurley.com> - 2023-04-15 20:50 +0200
            Re: Apt sources.list Jeffrey Walton <noloader@gmail.com> - 2023-04-16 02:40 +0200
              Re: Apt sources.list <paulf@quillandmouse.com> - 2023-04-16 14:50 +0200
      Re: Apt sources.list <paulf@quillandmouse.com> - 2023-04-15 16:50 +0200
      Re: Apt sources.list "Andrew M.A. Cater" <amacater@einval.com> - 2023-04-15 18:50 +0200
        Re: Apt sources.list Brian <ad44@cityscape.co.uk> - 2023-04-15 21:20 +0200
          Re: Apt sources.list "Andrew M.A. Cater" <amacater@einval.com> - 2023-04-15 22:20 +0200
            Re: Apt sources.list songbird <songbird@anthive.com> - 2023-04-16 00:00 +0200
            Re: Apt sources.list Stefan Monnier <monnier@iro.umontreal.ca> - 2023-04-16 06:20 +0200
              Re: Apt sources.list David Wright <deblis@lionunicorn.co.uk> - 2023-04-16 07:00 +0200
              Re: Apt sources.list "Andrew M.A. Cater" <amacater@einval.com> - 2023-04-16 13:20 +0200
                Re: Apt sources.list Frank <zuiderduin@gmx.com> - 2023-04-16 16:40 +0200
                  Re: Apt sources.list John Hasler <john@sugarbit.com> - 2023-04-16 18:20 +0200
            Re: Apt sources.list Frank <zuiderduin@gmx.com> - 2023-04-16 07:20 +0200
              Re: Apt sources.list David Wright <deblis@lionunicorn.co.uk> - 2023-04-16 16:40 +0200
        Re: Apt sources.list <paulf@quillandmouse.com> - 2023-04-15 22:10 +0200
    Re: Apt sources.list Tixy <tixy@yxit.co.uk> - 2023-04-15 18:20 +0200
      Re: Apt sources.list Frank <zuiderduin@gmx.com> - 2023-04-15 22:00 +0200
        Re: Apt sources.list Vincent Lefevre <vincent@vinc17.net> - 2023-04-18 16:40 +0200
          Re: Apt sources.list Frank <zuiderduin@gmx.com> - 2023-04-18 19:50 +0200
            Re: Apt sources.list Jeffrey Walton <noloader@gmail.com> - 2023-04-18 20:00 +0200
              Re: Apt sources.list Vincent Lefevre <vincent@vinc17.net> - 2023-04-20 12:20 +0200
                Re: Apt sources.list Greg Wooledge <greg@wooledge.org> - 2023-04-20 13:30 +0200

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

#257215 — Apt sources.list

Folks:

Here is my sources.list file:

---

deb http://debian.uchicago.edu/debian/ bookworm main contrib non-free
deb-src http://debian.uchicago.edu/debian/ bookworm main contrib non-free

deb http://security.debian.org/debian-security bookworm-security main
contrib non-free deb-src http://security.debian.org/debian-security bookworm-security main contrib non-free

---

According to https://www.debian.org/releases/, bookworm at this time is
"testing". But when the next release comes, bookworm will still be
bookworm, but "testing" will be bookworm "plus". I'd like to follow
testing, regardless of the status of Debian official releases.

So... in my sources.list, if I change "bookworm" to "testing", will it
do that, and (other than the instabilities of testing) is there any
liability to it?

Paul


-- 
Paul M. Foster
Personal Blog: http://noferblatz.com
Company Site: http://quillandmouse.com
Software Projects: https://gitlab.com/paulmfoster

[toc] | [next] | [standalone]

#257216

On Sat 15 Apr 2023 at 08:11:17 -0400, paulf@quillandmouse.com wrote:

> Folks:
> 
> Here is my sources.list file:
> 
> ---
> 
> deb http://debian.uchicago.edu/debian/ bookworm main contrib non-free
> deb-src http://debian.uchicago.edu/debian/ bookworm main contrib non-free
> 
> deb http://security.debian.org/debian-security bookworm-security main
> contrib non-free deb-src http://security.debian.org/debian-security bookworm-security main contrib non-free
> 
> ---
> 
> According to https://www.debian.org/releases/, bookworm at this time is
> "testing". But when the next release comes, bookworm will still be
> bookworm, but "testing" will be bookworm "plus". I'd like to follow
> testing, regardless of the status of Debian official releases.
> 
> So... in my sources.list, if I change "bookworm" to "testing", will it
> do that, and (other than the instabilities of testing) is there any
> liability to it?

bookworm to testing is exactly what you want.

-- 
Brian.

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

#257218

On Sat, Apr 15, 2023 at 01:23:05PM +0100, Brian wrote:
> On Sat 15 Apr 2023 at 08:11:17 -0400, paulf@quillandmouse.com wrote:
> > ---
> > 
> > deb http://debian.uchicago.edu/debian/ bookworm main contrib non-free
> > deb-src http://debian.uchicago.edu/debian/ bookworm main contrib non-free
> > 
> > deb http://security.debian.org/debian-security bookworm-security main
> > contrib non-free deb-src http://security.debian.org/debian-security bookworm-security main contrib non-free
> > 
> > ---

> > I'd like to follow
> > testing, regardless of the status of Debian official releases.

> bookworm to testing is exactly what you want.

That, and adding the non-free-firmware section.

https://wiki.debian.org/NewInBookworm

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

#257221

On Sat, Apr 15, 2023 at 08:52:06AM -0400, Greg Wooledge wrote:
> On Sat, Apr 15, 2023 at 01:23:05PM +0100, Brian wrote:
> > On Sat 15 Apr 2023 at 08:11:17 -0400, paulf@quillandmouse.com wrote:
> > > ---
> > > 
> > > deb http://debian.uchicago.edu/debian/ bookworm main contrib non-free
> > > deb-src http://debian.uchicago.edu/debian/ bookworm main contrib non-free
> > > 
> > > deb http://security.debian.org/debian-security bookworm-security main
> > > contrib non-free deb-src http://security.debian.org/debian-security bookworm-security main contrib non-free
> > > 
> > > ---

While we are talking about this, is there any reason why all the http: should
not be https: ?

I have done this on my own machine without ill effect.

-- 
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer.
+44 (0) 787 668 0256  https://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information: https://www.phcomp.co.uk/Contact.html
#include <std_disclaimer.h>

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

#257222

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

On Sat, Apr 15, 2023 at 02:01:27PM +0100, Alain D D Williams wrote:

[...]

> While we are talking about this, is there any reason why all the http: should
> not be https: ?

It's just unnecessary CPU on the server, that's all.

Cheers
-- 
t

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

#257223

On Sat, Apr 15, 2023 at 03:48:31PM +0200, tomas@tuxteam.de wrote:
> On Sat, Apr 15, 2023 at 02:01:27PM +0100, Alain D D Williams wrote:
> 
> [...]
> 
> > While we are talking about this, is there any reason why all the http: should
> > not be https: ?
> 
> It's just unnecessary CPU on the server, that's all.

That used to be the case many years ago. Modern CPUs have instructions that
make it much quicker.

"On our production frontend machines, SSL/TLS accounts for less than 1% of the
CPU load, less than 10 KB of memory per connection and less than 2% of network
overhead."

https://istlsfastyet.com/

-- 
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer.
+44 (0) 787 668 0256  https://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information: https://www.phcomp.co.uk/Contact.html
#include <std_disclaimer.h>

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

#257225

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

On Sat, Apr 15, 2023 at 02:59:49PM +0100, Alain D D Williams wrote:
> On Sat, Apr 15, 2023 at 03:48:31PM +0200, tomas@tuxteam.de wrote:
> > On Sat, Apr 15, 2023 at 02:01:27PM +0100, Alain D D Williams wrote:
> > 
> > [...]
> > 
> > > While we are talking about this, is there any reason why all the http: should
> > > not be https: ?
> > 
> > It's just unnecessary CPU on the server, that's all.
> 
> That used to be the case many years ago. Modern CPUs have instructions that
> make it much quicker.

It may be /less/ than it used to be (what would interest me
is the overall energy consumption, joules/megabyte or so).
But it is nonzero.

And still, it's unnecessary.

Cheers
-- 
t

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

#257224

On Sat 15 Apr 2023 at 14:01:27 +0100, Alain D D Williams wrote:

> On Sat, Apr 15, 2023 at 08:52:06AM -0400, Greg Wooledge wrote:
> > On Sat, Apr 15, 2023 at 01:23:05PM +0100, Brian wrote:
> > > On Sat 15 Apr 2023 at 08:11:17 -0400, paulf@quillandmouse.com wrote:
> > > > ---
> > > > 
> > > > deb http://debian.uchicago.edu/debian/ bookworm main contrib non-free
> > > > deb-src http://debian.uchicago.edu/debian/ bookworm main contrib non-free
> > > > 
> > > > deb http://security.debian.org/debian-security bookworm-security main
> > > > contrib non-free deb-src http://security.debian.org/debian-security bookworm-security main contrib non-free
> > > > 
> > > > ---
> 
> While we are talking about this, is there any reason why all the http: should
> not be https: ?
> 
> I have done this on my own machine without ill effect.

By all means use https, but bear in mind that Debian has gone to great lengths
to implement package distribution security which doesn't really depend at all
on transport layer encryption. 

-devel has seen a number of didcussions on thia topic.

-- 
Brian.

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

#257226

On Sat, 15 Apr 2023 14:01:27 +0100
Alain D D Williams <addw@phcomp.co.uk> wrote:

> While we are talking about this, is there any reason why all the
> http: should not be https: ?
> 
> I have done this on my own machine without ill effect.

One reason is if one is using a local cache which does not inspect
https streams. Last I knew, such local caches included apt-cacher-ng.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

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

#257228

On Sat, 15 Apr 2023 14:01:27 +0100
Alain D D Williams <addw@phcomp.co.uk> wrote:

> On Sat, Apr 15, 2023 at 08:52:06AM -0400, Greg Wooledge wrote:
> > On Sat, Apr 15, 2023 at 01:23:05PM +0100, Brian wrote:
> > > On Sat 15 Apr 2023 at 08:11:17 -0400, paulf@quillandmouse.com
> > > wrote:
> > > > ---
> > > > 
> > > > deb http://debian.uchicago.edu/debian/ bookworm main contrib
> > > > non-free deb-src http://debian.uchicago.edu/debian/ bookworm
> > > > main contrib non-free
> > > > 
> > > > deb http://security.debian.org/debian-security
> > > > bookworm-security main contrib non-free deb-src
> > > > http://security.debian.org/debian-security bookworm-security
> > > > main contrib non-free
> > > > 
> > > > ---
> 
> While we are talking about this, is there any reason why all the
> http: should not be https: ?
> 
> I have done this on my own machine without ill effect.
> 

Okay. Let's open this can of worms. The ONLY reason https is used on
most sites is because Google *mandated* it years ago. ("Mandate" means
we'll downgrade your search ranking if you don't use https.) There is
otherwise no earthly reason to have an encrypted connection to a web
server unless there is some exchange of private information between you
and the server.

Reading through all of Google's explanations, I've never seen a
satisfactory explanation for this change. With that in mind, I believe
the Debian gods did the right thing in leaving their web connections
"insecure". Though, in truth, the integrity of Debian server contents
wouldn't be changed in the slightest whether the connection was
encrypted or not.

Paul


-- 
Paul M. Foster
Personal Blog: http://noferblatz.com
Company Site: http://quillandmouse.com
Software Projects: https://gitlab.com/paulmfoster

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

#257231

paulf@quillandmouse.com wrote: 
> 
> Okay. Let's open this can of worms. The ONLY reason https is used on
> most sites is because Google *mandated* it years ago. ("Mandate" means
> we'll downgrade your search ranking if you don't use https.) There is
> otherwise no earthly reason to have an encrypted connection to a web
> server unless there is some exchange of private information between you
> and the server.

... and because Let's Encrypt made it relatively easy,
monetarily free, and automated.


> "insecure". Though, in truth, the integrity of Debian server contents
> wouldn't be changed in the slightest whether the connection was
> encrypted or not.


It's nice not to be telling everyone who can sniff a plaintext
connection which packages you are installing, and prevents those
people from trivially substituting trojan horses.

-dsr-

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

#257238

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

On Sat, Apr 15, 2023 at 12:18:57PM -0400, Dan Ritter wrote:
> paulf@quillandmouse.com wrote: 
> > 
> > Okay. Let's open this can of worms. The ONLY reason https is used on
> > most sites is because Google *mandated* it years ago. ("Mandate" means
> > we'll downgrade your search ranking if you don't use https.) There is
> > otherwise no earthly reason to have an encrypted connection to a web
> > server unless there is some exchange of private information between you
> > and the server.
> 
> ... and because Let's Encrypt made it relatively easy,
> monetarily free, and automated.

Google Chrome being one of their sponsors.

Now don't get me wrong: there are many things to like about TLS in
general and about Let's Encrypt in particular. And another sponsor
of Let's Encrypt is the EFF, whose motives, to me at least, are
beyond reproach. But it's a mixed bag, and that "unencrypted is
BAAAD" meme is just security theater.

> > "insecure". Though, in truth, the integrity of Debian server contents
> > wouldn't be changed in the slightest whether the connection was
> > encrypted or not.
> 
> 
> It's nice not to be telling everyone who can sniff a plaintext
> connection which packages you are installing,

Without doubt, this is an advantage of a TLS connection. If you
do care about that, here would be one reason.

>                                        and prevents those
> people from trivially substituting trojan horses.

...and this is downright wrong. The Debian packages are signed.
If you got your first install from a trusted source, this is
way more secure than TLS [1]. TLS doesn't hurt here, but it
doesn't help much, either.

[1] Have you ever had a look at the incredible zoo of root certs
your browser trusts?

Cheers
-- 
t

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

#257253

On Sat, 15 Apr 2023 tomas@tuxteam.de wrote:
> On Sat, Apr 15, 2023 at 12:18:57PM -0400, Dan Ritter wrote:
>> paulf@quillandmouse.com wrote:
>>>
>>> Okay. Let's open this can of worms.

I wish more would.

>>> The ONLY reason https is used on most sites is because Google
>>> *mandated* it years ago. ("Mandate" means we'll downgrade your
>>> search ranking if you don't use https.) There is otherwise no
>>> earthly reason to have an encrypted connection to a web server
>>> unless there is some exchange of private information between you
>>> and the server.
>>
>> ... and because Let's Encrypt made it relatively easy, monetarily
>> free, and automated.

Who doesn't love free tickets to the security theatre?

> Google Chrome being one of their sponsors.
>
> Now don't get me wrong: there are many things to like about TLS in
> general and about Let's Encrypt in particular. And another sponsor
> of Let's Encrypt is the EFF, whose motives, to me at least, are
> beyond reproach.

That the EFF is "beyond reproach" is quite a strong statement. Once
upon a time, I would have agreed.

I am no longer so confident. Institutions that pose a genuine threat
(to the agenda of the powers that be) get captured. One must seek out
and examine evidence that contradicts beliefs that make one feel safe.

Placing an institution "beyond reproach" prevents that practice.

> But it's a mixed bag, and that "unencrypted is BAAAD" meme is just
> security theater.

Security theatre is never cost-free, and always has a purpose. Whose
purpose? Who pays for it? And who endorsed propaganda in favor of its
institution?

>>> "insecure". Though, in truth, the integrity of Debian server contents
>>> wouldn't be changed in the slightest whether the connection was
>>> encrypted or not.
>>
>>
>> It's nice not to be telling everyone who can sniff a plaintext
>> connection which packages you are installing,
>
> Without doubt, this is an advantage of a TLS connection. If you
> do care about that, here would be one reason.

In case you wish to obscure what software you *install*, but need not
conceal the software you *download*:

  Step one: Make a list of the packages you want, and then augment it
  with as many plausible alternatives and red herrings as you like.

  Step two:
  $ apt-get -d install <many packages>

This downloads the packages only, so you can download packages you
will *not* install, along with ones you will. Then install the proper
subset you want installed, without the '-d' option.

This is more work *for you* than TLS (supposing you don't automate
alternative/red-herring selection). More work for you may be worth the
cost, if the work is effective. This method does not rely on
certificates and "trusted" authorities.

As already mentioned, it does not prevent observers from noticing that
you *downloaded* something forbidden.

>> and prevents those people from trivially substituting trojan
>> horses.

Setting aside the question of what class of actors are (or are not) so
thwarted, I was surprised to read this. A clarification or elaboration
might be interesting.

Sufficient clarity and necessary precision often work against one
another.

> ...and this is downright wrong.

Or perhaps incomplete. I too did a double-take, though, and would like
to hear more.

> The Debian packages are signed.

Q: Waaah. Stupid APT won't verify a key.
A: Easy peasy. [Demonstrates how to retrieve and trust attacker's key]
Q: Thanks a lot, anon. It worked!

>  If you got your first install from a trusted source, this is way
> more secure than TLS [1]. TLS doesn't hurt here, but it doesn't help
> much, either.
>
> [1] Have you ever had a look at the incredible zoo of root certs
> your browser trusts?

What's wrong, Tomas? Don't you want to watch pornographic videos and
conduct your banking with the same application?

-- 
Hackers are free people. They are like artists. If they are in a good
mood, they get up in the morning and begin painting their pictures.
-- Vladimir Putin

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

#257256

On Sat, Apr 15, 2023 at 10:54:10PM +0000, davidson wrote:
> In case you wish to obscure what software you *install*, but need not
> conceal the software you *download*:
> 
>  Step one: Make a list of the packages you want, and then augment it
>  with as many plausible alternatives and red herrings as you like.
> 
>  Step two:
>  $ apt-get -d install <many packages>
> 
> This downloads the packages only, so you can download packages you
> will *not* install, along with ones you will. Then install the proper
> subset you want installed, without the '-d' option.

I'm at a loss as to what threat model this is supposed to protect against.
In the obvious one ("Comrade Davidson has downloaded package A.  Let's
bump up the priority of his surveillance."), downloading flagged package A
*and* possibly-flagged package B is just going to make your situation
worse, not better.

Now, personally I don't feel this is a threat model that I need to
worry about.  I just use plain old http sources at home, and if "They"
learn that I've downloaded rxvt-unicode and mutt, well, good for Them.

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

#257257

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

On 2023-04-15 at 19:11, Greg Wooledge wrote:

> On Sat, Apr 15, 2023 at 10:54:10PM +0000, davidson wrote:
> 
>> In case you wish to obscure what software you *install*, but need
>> not conceal the software you *download*:
>> 
>> Step one: Make a list of the packages you want, and then augment
>> it with as many plausible alternatives and red herrings as you
>> like.
>> 
>> Step two: $ apt-get -d install <many packages>
>> 
>> This downloads the packages only, so you can download packages you 
>> will *not* install, along with ones you will. Then install the
>> proper subset you want installed, without the '-d' option.
> 
> I'm at a loss as to what threat model this is supposed to protect
> against.

My guess is that it's supposed to make it harder for people to guess
what exploits your computer may be vulnerable to, by obfuscating which
of the various packages you downloaded are actually installed and
therefore potentially in use.

<snip>

> Now, personally I don't feel this is a threat model that I need to 
> worry about.  I just use plain old http sources at home, and if
> "They" learn that I've downloaded rxvt-unicode and mutt, well, good
> for Them.

My understanding is that mandating HTTPS for all connections is supposed
to make it so that those who might be watching can't treat the choice by
the user to connect via HTTPS as a sign that the user has something to
hide, and therefore is worth observing more closely.

I seem to remember having seen suggestions that some regimes might even
prohibit the use of HTTPS entirely, so as to ensure that they can spy on
their subjects' connections, and that such a prohibition would be less
practical for them to impose if everything requires HTTPS. I'm not sure
about the real-world basis for that, however.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

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

#257261

>> Now, personally I don't feel this is a threat model that I need to 
>> worry about.  I just use plain old http sources at home, and if
>> "They" learn that I've downloaded rxvt-unicode and mutt, well, good
>> for Them.
> My understanding is that mandating HTTPS for all connections is supposed
> to make it so that those who might be watching can't treat the choice by
> the user to connect via HTTPS as a sign that the user has something to
> hide, and therefore is worth observing more closely.

My understanding is that the effect has been (in intelligence agencies
around the world) to push the development of attacks/tools that target
the ends of the connections rather than trying to spy on the
connections themselves.


        Stefan

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

#257260

On Sat, 15 Apr 2023 Greg Wooledge wrote:
> On Sat, Apr 15, 2023 at 10:54:10PM +0000, davidson wrote:
>> In case you wish to obscure what software you *install*, but need not
>> conceal the software you *download*:
>>
>>  Step one: Make a list of the packages you want, and then augment it
>>  with as many plausible alternatives and red herrings as you like.
>>
>>  Step two:
>>  $ apt-get -d install <many packages>
>>
>> This downloads the packages only, so you can download packages you
>> will *not* install, along with ones you will. Then install the proper
>> subset you want installed, without the '-d' option.
>
> I'm at a loss as to what threat model this is supposed to protect
> against.

The answer to *that* question was written on the tin.

Instead, you mean to question the existence of actors who *do* care
what some administrator installs, but do not care what they download.

An entirely fair question. Their existence is a logical possibility.
Since you ask, I don't think their presence is inconceivable.

Ritter wrote...

   "It's nice not to be telling everyone who can sniff a plaintext
   connection which packages you are installing"

I consider it an interesting problem.

> In the obvious one ("Comrade Davidson has downloaded package A.  Let's
> bump up the priority of his surveillance."), downloading flagged package A
> *and* possibly-flagged package B is just going to make your situation
> worse, not better.

I explicitly stated, twice (both from the start, and at the conclusion
trimmed by you) that the method does NOT apply to such a threat model.

So here you have helpfully provided a hypothetical narrative to
illustrate a point I wished to make extremely clear.

> Now, personally I don't feel this is a threat model that I need to
> worry about.  I just use plain old http sources at home, and if
> "They" learn that I've downloaded rxvt-unicode and mutt, well, good
> for Them.

We do not seem to be having an argument.

-- 
Hackers are free people. They are like artists. If they are in a good
mood, they get up in the morning and begin painting their pictures.
-- Vladimir Putin

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

#257312

On Sat, 15 Apr 2023, Greg Wooledge wrote:

>
> Now, personally I don't feel this is a threat model that I need to
> worry about.  I just use plain old http sources at home, and if "They"
> learn that I've downloaded rxvt-unicode and mutt, well, good for Them.
>
>

The thread model I'm most concerned about is local stuff *exporting*
data elsewhere.

I do understand that there are people in some parts of the world that
want to do things that they ought to be allowed to do but their
repressive governments are preventing. HTTPS is a useful tool to make
that repression harder - but doesn't actually make people safe - if
doing something is illegal then it's still illegal even if it's harder
for the authorities to detect it.

But it's pretty much impossible nowadays to have a "safe" environment at
home. Phones, TVs, almost everything, now tries to establish outgoing
connections.

ESNI, and DNSoHTTPS are on the way to making it almost impossible to
keep tabs on this and restrict what is allowed to egress.

The only redeeming point is that corporates *need* to do egress
filtering - so at the moment the browsers cannot totally block it - and
if they did try, there would be the financing to provide a browser that
corporates could use that, at least, allowed SNI sniffing and regular
DNS.

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

#257314

On Sun, Apr 16, 2023 at 3:06 PM Tim Woodall <debianuser@woodall.me.uk> wrote:
>
> On Sat, 15 Apr 2023, Greg Wooledge wrote:
>
> > Now, personally I don't feel this is a threat model that I need to
> > worry about.  I just use plain old http sources at home, and if "They"
> > learn that I've downloaded rxvt-unicode and mutt, well, good for Them.
>
> The thread model I'm most concerned about is local stuff *exporting*
> data elsewhere.
>
> I do understand that there are people in some parts of the world that
> want to do things that they ought to be allowed to do but their
> repressive governments are preventing. HTTPS is a useful tool to make
> that repression harder - but doesn't actually make people safe - if
> doing something is illegal then it's still illegal even if it's harder
> for the authorities to detect it.
>
> But it's pretty much impossible nowadays to have a "safe" environment at
> home. Phones, TVs, almost everything, now tries to establish outgoing
> connections.
>
> ESNI, and DNSoHTTPS are on the way to making it almost impossible to
> keep tabs on this and restrict what is allowed to egress.
>
> The only redeeming point is that corporates *need* to do egress
> filtering - so at the moment the browsers cannot totally block it - and
> if they did try, there would be the financing to provide a browser that
> corporates could use that, at least, allowed SNI sniffing and regular
> DNS.

Corporations don't need browser cooperation for Data Loss Prevention
(DLP) (but they already have it). Corporations just run an
interception proxy, like NetSkope. The NetScope Root CA is loaded into
every browser trust store. The application will terminate all traffic,
inspect it, and forward the request if it looks innocuous.

The W3C and Browsers have already decided "interception is a valid use
case." That boat has already sailed. The browsers claim authority
comes from Priority of Constituencies under the Web Design Principles.
I argued against it until I was blue in the face. Also see
https://www.w3.org/TR/html-design-principles/#priority-of-constituencies.

The conspiracy runs even deeper. App developers cannot ask a WebSocket
for the certificate or public key used to setup the secure channel. If
an app/JavaScript could get the info, then it could determine the
connection was intercepted. The browsers don't want app authors
knowing that because "interception is a valid use case." So the W3C
and Browsers have baked interception into the model, and then
neutered/crippled the technologies to ensure the agenda is moved
forward.

Jeff

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

#257316

On Sun, Apr 16, 2023 at 4:52 PM Jeffrey Walton <noloader@gmail.com> wrote:
>
> On Sun, Apr 16, 2023 at 3:06 PM Tim Woodall <debianuser@woodall.me.uk> wrote:
> >
> > On Sat, 15 Apr 2023, Greg Wooledge wrote:
> >
> > > Now, personally I don't feel this is a threat model that I need to
> > > worry about.  I just use plain old http sources at home, and if "They"
> > > learn that I've downloaded rxvt-unicode and mutt, well, good for Them.
> >
> > The thread model I'm most concerned about is local stuff *exporting*
> > data elsewhere.
> >
> > I do understand that there are people in some parts of the world that
> > want to do things that they ought to be allowed to do but their
> > repressive governments are preventing. HTTPS is a useful tool to make
> > that repression harder - but doesn't actually make people safe - if
> > doing something is illegal then it's still illegal even if it's harder
> > for the authorities to detect it.
> >
> > But it's pretty much impossible nowadays to have a "safe" environment at
> > home. Phones, TVs, almost everything, now tries to establish outgoing
> > connections.
> >
> > ESNI, and DNSoHTTPS are on the way to making it almost impossible to
> > keep tabs on this and restrict what is allowed to egress.
> >
> > The only redeeming point is that corporates *need* to do egress
> > filtering - so at the moment the browsers cannot totally block it - and
> > if they did try, there would be the financing to provide a browser that
> > corporates could use that, at least, allowed SNI sniffing and regular
> > DNS.
>
> Corporations don't need browser cooperation for Data Loss Prevention
> (DLP) (but they already have it). Corporations just run an
> interception proxy, like NetSkope. The NetScope Root CA is loaded into
> every browser trust store. The application will terminate all traffic,
> inspect it, and forward the request if it looks innocuous.

To be clear... The NetSkope Root CA is loaded into browsers for
computers owned by the corporation. I.e., part of the corporation's
standard image.

The NetSkope Root CA is _not_part of Mozilla, Chrome, Edge, Opera,
etc., trust store.

(After re-reading, it sounded like I was stating the latter).

Jeff

> The W3C and Browsers have already decided "interception is a valid use
> case." That boat has already sailed. The browsers claim authority
> comes from Priority of Constituencies under the Web Design Principles.
> I argued against it until I was blue in the face. Also see
> https://www.w3.org/TR/html-design-principles/#priority-of-constituencies.
>
> The conspiracy runs even deeper. App developers cannot ask a WebSocket
> for the certificate or public key used to setup the secure channel. If
> an app/JavaScript could get the info, then it could determine the
> connection was intercepted. The browsers don't want app authors
> knowing that because "interception is a valid use case." So the W3C
> and Browsers have baked interception into the model, and then
> neutered/crippled the technologies to ensure the agenda is moved
> forward.
>
> Jeff

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

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

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

csiph-web