Re: Keysafe dynamic UID

[Tollef Fog Heen]

]] Christian Seiler 

> On 10/24/2016 12:42 AM, Colin Watson wrote:
> > On Sat, Oct 22, 2016 at 02:57:23PM -0700, Sean Whitton wrote:
> >> I am packaging Keysafe,[1] and the binary package keysafe-server needs
> >> to create a new system user with a dynamically allocated UID.
> >>
> >> I am using the username 'keysafe'.  I do not anticipate any collision
> >> with any other package, but policy says I should e-mail you to confirm
> >> that.
> > 
> > Policy should probably only suggest emailing the base-passwd maintainer
> > in the case where you need a statically-allocated ID
> 
> The requirement to have this for dynamically allocated IDs also
> probably stems from the fact that the users created in postinst scripts
> should not conflict. But wouldn't it be far easier to just create a
> page on the Debian Wiki and track that there? [1] And have policy say
> to check that list to see that it's unique and add your package + user
> there when you are about to upload a new package? That way, in 99.9% of
> cases where users are required, and they don't conflict with existing
> ones, there's no additional work for people other than the package
> maintainer, and the package maintainer doesn't have to wait for a
> response before they are able to proceed. And if there really is a
> conflict, people can still post to -devel about it.

I'd prefer if user creation was just done declaratively and then we
could scan the archive.  If we have a manually-maintained list, it will
get out of sync with reality pretty quickly.

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

Re: client-side signature checking of Debian archives (Re: When should we https our mirrors?)

[Eugene V. Lyubimkin]

Hi Russ, Kristian,

On 24.10.2016 07:19, Kristian Erik Hermansen wrote:
> On Sun, Oct 23, 2016 at 7:28 PM, Russ Allbery  wrote:
>> The idea is to *add* HTTPS protection on top of the protections we already
>> have.  You're correct that it doesn't give you authentication of the
>> packages without a bunch of work, and we should assume that the general
>> public CA system is compromised.  But that actually doesn't matter much
>> for our purposes, since the point is to greatly increase the cost of
>> gathering data about what packages people have installed.
>>
>> The value of HTTPS lies in its protection against passive snooping.  Given
> 
> Exactly! Much better said than how I originally phrased these issues.
> 
>> what package and at what version.  HTTPS doesn't *prevent* this, but it
>> requires the attacker to do much more sophisticated traffic analysis, or
>> take the *much* more expensive and *far* riskier step of moving to active
>> interference with traffic, neither of which nation-state attackers want to
>> do and neither of which they have the resources to do *routinely*.
>>
>> It won't help if a nation-state actor is targeting you *in particular*.
>> But it helps immensely against dragnet surveillance.
> 
> Again, exactly right and well stated. We can never stop targeted
> attacks, but we can make passive data collection more expensive and
> increase the chances that a targeted attack is detected.

Yes, thank you for explanations, I now get the point of improving more 
confidentiality than integrity here, and warding
off most of passive data gatherers.

Re: When should we https our mirrors?

[Tollef Fog Heen]

]] Philipp Kern 

> On 10/18/2016 06:47 PM, Marco d'Itri wrote:
> > On Oct 17, Ian Campbell  wrote:
> >> Have we gotten to the point where we consider deb.d.o suitable for
> >> production use? The web page still says Experimental (so I would assume
> > I do not think that it is appropriate for general use, since at least 
> > one of the CDNs backing it lacks nodes in many (most) countries.
> > I like to get my Debian packages over peering links. :-)
> 
> It's also a little awkward that apt does not tell you which of the SRV
> records it picked. (The "and why" is clear: round robin.) I had a short
> read earlier today and I had no idea how to even report it without that
> information. (Of course I know how to turn on debugging but then it
> picked a different one and succeeded.)

Even getting the SRV record won't help much, you want to know what IP it
resolved to and what headers you got from the backend to uniquely
identify problems with a single POP or machine in a POP.

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

Re: Keysafe dynamic UID

[Christian Seiler]

On 10/24/2016 09:12 AM, Tollef Fog Heen wrote:
> I'd prefer if user creation was just done declaratively and then we
> could scan the archive.  If we have a manually-maintained list, it will
> get out of sync with reality pretty quickly.

Doing this declaratively would definitely be the ideal solution, no
question. (In fact, a lot of things done in postinst now could and
IMHO should be done declaratively, such as system services in most
trivial cases, and so on.) But then you'd need to first survey the
archive to see what things the declarative system would need to
address, and then for an automated scan of the archive to yield good
results a LOT of packages would have to be switched to the new
declarative style. I think this is a very worthy long-term goal, but
even mid-term I don't see this as being realistic. Plus, if we had a
list now, it would definitely help the people who'd then be working
on implementing the declarative system. (They'd have an overview of
which packages would be affected, and it'd be easier to to MBF when
the system is in place, etc.)

Consider that only a fraction of packages actually create users, so
while desyncing of the list is a real issue, it's not like this will
happen _that_ fast.

In the spirit of "perfect is the enemy of good", I think my proposal
is an improvement on the current situation. And I did say I'd
volunteer to create the initial list.

Regards,
Christian

Re: [Pkg-dns-devel] Bug#833309: "Browserified" stuff (knot-resolver-module-http: please package embedded epoch.js separately)

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Fri, Oct 21, 2016 at 07:26:43AM +0200, Vincent Bernat wrote:
> It would be as easy for the security team to modify the unminified version
> than the "upper" upstream version of the source.

The release team has just decided that "browserified" files are not source.
Please stop suggesting that they are just a different kind of source; if you
really want to claim that, start a GR over it to overrule the release team.
(Please don't; it'd be a waste of time because AFAICS it stands no chance of
passing, in fact I'd be surprised if you'd get enough seconds.)

> I suppose that (like me), Ondřej Surý does not want to deal with the
> complexity of building JS from the "upper" source for the benefit of
> people that don't exist.

Aside from the fact that those people don't need to exist, as stated in another
email, they do.  I'm one of them.  The fact that I can retrieve the source of
the software I'm using and it will actually build from that source is one of
the main features that I like Debian for.  And when I make changes, I want to
send them back upstream, so "browserified" files are not good enough for me.

Thanks,
Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJYDbqYAAoJEJzRfVgHwHE64SIP/RpZOrqwXyvWRKyqE1+2rBiz
GRxe0NLHK5OBGkg64P3jwQyz+FrH44U5OQ3GrJgOzRkaqFCb37guZYy+fhpFa7DX
HwxT/fB+woQwry5dOs0jicmT8xEp+mQqBKRI8jM/BX73LVfInsOb6XVzSFEMkvSj
O8L7+0Q7lmHOHizmPCbM311fNkWYkdVzabSUb4/1vnQZYqZKVp6wr+W0f6mZi040
ULHstz6HhcjWXEKnbxc3Ey6biDZNSF71vP/N3rTN5Kkk/kJ9/dr0NInzF3Uzw2su
8y803eh0uucEE+LXxe1BoD3KOi7FEZX37wC5ogSvWCHvq1mddYZPxIUgf/4lZRdp
JalQ1XvUyNB+nW/p7L/9+Tn6aYSyCQ84Kas9Y9PaymzTuBa2XrCuhY2h2k6/v+SX
t+PmyzX3oeBVscPWq/aP3Ee/uf3g3y6YNuIBjaLD9gFipvz2g/E7mZ58f41LdPWd
V+bYptYtv+essnldA/0Pck+fRA9mpSWrJ8PR98CuAgdZ11n9LkgS/xmYwvXWDOZZ
y7VslGA8LkO8Pn8tWSVMKSBSPjwHqKixWgG41zq7PKqVdT4b37cWAMCGgGwJRIwC
rWInHvmDDtw5RoT7JVFZcUnxw2RWuOcIeRLyHlKmFOZNls0bTlFbre00KYAp7zXP
mkD0wNL6TxTu/HDH4MQf
=p3i7
-END PGP SIGNATURE-

Re: Keysafe dynamic UID

[Vincent Bernat]

 ❦ 24 octobre 2016 09:12 +0200, Tollef Fog Heen  :

>> The requirement to have this for dynamically allocated IDs also
>> probably stems from the fact that the users created in postinst scripts
>> should not conflict. But wouldn't it be far easier to just create a
>> page on the Debian Wiki and track that there? [1] And have policy say
>> to check that list to see that it's unique and add your package + user
>> there when you are about to upload a new package? That way, in 99.9% of
>> cases where users are required, and they don't conflict with existing
>> ones, there's no additional work for people other than the package
>> maintainer, and the package maintainer doesn't have to wait for a
>> response before they are able to proceed. And if there really is a
>> conflict, people can still post to -devel about it.
>
> I'd prefer if user creation was just done declaratively and then we
> could scan the archive.  If we have a manually-maintained list, it will
> get out of sync with reality pretty quickly.

dh-sysuser entered the archive recently.
-- 
Terminate input by end-of-file or marker, not by count.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Bug#841892: ITP: golang-github-twstrike-otr3 -- Go implementation of the OTR 3 protocol

[Sascha Steinbiss]

Package: wnpp
Severity: wishlist
Owner: Sascha Steinbiss 

* Package name: golang-github-twstrike-otr3
  Version : 0.0~git20161015.0.744856d-1
  Upstream Author : STRIKE Team
* URL : https://github.com/twstrike/otr3
* License : GPL-3.0
  Programming Lang: Go
  Description : Go implementation of the OTR 3 protocol

OTR3 implements version 3 of the OTR standard in Go.
Implements feature parity with libotr 4.1.0.

This is packaged as a dependency for CoyIM.

Bug#841893: ITP: golang-github-gotk3-gotk3 -- Go bindings for GTK3

[Sascha Steinbiss]

Package: wnpp
Severity: wishlist
Owner: Sascha Steinbiss 

* Package name: golang-github-gotk3-gotk3
  Version : GOTK3_0_2_0+git20161020.501.2caa15f-1
  Upstream Author : Conformal Systems LLC.
* URL : https://github.com/gotk3/gotk3
* License : ISC
  Programming Lang: Go
  Description : Go bindings for GTK3

The gotk3 project provides Go bindings for GTK+3 and dependent projects.   
Each component is given its own subdirectory, which is used as the 
import path for the package.   
  
Partial binding support for the following libraries is currently implemented:  
  
  - GTK+3 (3.12 and later) 
  - GDK 3 (3.12 and later) 
  - GLib 2 (2.36 and later)
  - Cairo (1.10 and later) 
  
Care has been taken for memory management to work seamlessly with Go's 
garbage collector without the need to use or understand GObject's floating 
references.

This is packaged as a dependency of CoyIM.

Bug#841900: ITP: node-builtin-modules -- List of the Node.js builtin modules

[Sruthi Chandran]

Package: wnpp
Severity: wishlist
Owner: Sruthi Chandran 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: node-builtin-modules
  Version : 1.1.1
  Upstream Author : Sindre Sorhus 
(sindresorhus.com)
* URL : https://github.com/sindresorhus/builtin-modules#readme
* License : Expat
  Programming Lang: JavaScript
  Description : List of the Node.js builtin modules

Bug#841899: ITP: golang-github-twstrike-gotk3adapter -- adapters and interfaces for gotk3

[Sascha Steinbiss]

Package: wnpp
Severity: wishlist
Owner: Sascha Steinbiss 

* Package name: golang-github-twstrike-gotk3adapter
  Version : 0.0~git20160819.0.3499960-1
  Upstream Author : STRIKE Team
* URL : https://github.com/twstrike/gotk3adapter
* License : GPL-3.0
  Programming Lang: Go
  Description : adapters and interfaces for gotk3

gotk3adapter contains adapters and interfaces for gotk3 in order to make
testing possible.

This is packaged as a dependency of CoyIM.

Bug#841898: ITP: golang-github-hydrogen18-stalecucumber -- Reader and writer for Python's pickle format in Golang

[Sascha Steinbiss]

Package: wnpp
Severity: wishlist
Owner: Sascha Steinbiss 

* Package name: golang-github-hydrogen18-stalecucumber
  Version : 0.0~git20161012.0.cd9ec28-1
  Upstream Author : Eric Urban
* URL : https://github.com/hydrogen18/stalecucumber
* License : BSD-2-clause
  Programming Lang: Go
  Description : Reader and writer for Python's pickle format in Golang

stalecucumber reads and writes pickled data. The format is
the same as the Python "pickle" module.

Protocols 0,1,2 are implemented. These are the versions written by the
Python 2.x series. Python 3 defines newer protocol versions, but can
write the older protocol versions so they are readable by this package.

This is packaged as a dependency of CoyIM.

Re: When should we https our mirrors?

[Adrian Bunk]

On Sun, Oct 23, 2016 at 06:04:50AM -0700, Kristian Erik Hermansen wrote:
>...
> The main issue is that a well positioned attacker, such as the NSA or
> Chinese router admins, have the ability to collect and analyze in
> real-time what systems have installed what patches installed by
> monitoring the historical / real-time patch requests downloaded to
> Debian systems.
>...

It is a common misconception that https could help against these kinds 
of attacks.

https is an improvement over http and it would be good if Debian could  
switch to https by default in stretch, but for the problem you are 
talking about it does not really make a difference.

https can obfuscate the traffic enough that a casual observer
has problems determining what exactly is being transferred.

If someone like the NSA is analyzing all your traffic, then the 
information when and how much data gets transferred should be
sufficient to deduce exactly the information you are worried about.

apt-transport-tor is the only option that has a realistic chance of 
helping you, unless you want to run a mirror of Debian in your network. 
Anyone who is seriously worried about these issues and has a clue about 
security will end up doing something like that.

For the kind of attacks you are describing, https is just snake oil.

> Regards,

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#841901: ITP: golang-github-thecreeper-go-notify -- implementation of the GNOME DBus Notifications Specification

[Sascha Steinbiss]

Package: wnpp
Severity: wishlist
Owner: Sascha Steinbiss 

* Package name: golang-github-thecreeper-go-notify
  Version : 0.0~git20160203.0.b5cd147-1
  Upstream Author : 
* URL : https://github.com/TheCreeper/go-notify
* License : BSD-2-clause
  Programming Lang: Go
  Description : Go implementation of the GNOME DBus Notifications 
Specification

The package notify provides a Go implementation of the GNOME DBus Notifications
Specification (https://developer.gnome.org/notification-spec).

This is packaged as a dependency of CoyIM.

Bug#841902: ITP: golang-github-voxelbrain-goptions -- flexible Go parser for command line options

[Sascha Steinbiss]

Package: wnpp
Severity: wishlist
Owner: Sascha Steinbiss 

* Package name: golang-github-voxelbrain-goptions
  Version : 2.5.11-1
  Upstream Author : voxelbrain
* URL : https://github.com/voxelbrain/goptions
* License : BSD-3-clause
  Programming Lang: Go
  Description : flexible Go parser for command line options

goptions implements a flexible parser for command line options in Go.

Key targets were the support for both long and short flag versions, mutually
exclusive flags, and verbs. Flags and their corresponding variables are defined
by the tags in a (possibly anonymous) struct.

Bug#841905: ITP: golang-github-dhowett-go-plist -- pure Go Apple Property List transcoder

[Sascha Steinbiss]

Package: wnpp
Severity: wishlist
Owner: Sascha Steinbiss 

* Package name: golang-github-dhowett-go-plist
  Version : 0.0~git20160708.0.fec78c8-1
  Upstream Author : Dustin L. Howett
* URL : https://github.com/dhowett/go-plist
* License : BSD
  Programming Lang: Go
  Description : pure Go Apple Property List transcoder

Plist is a Apple Property List transcoder written in pure Go. It supports
encoding/decoding property lists (Apple XML, Apple Binary, OpenStep and
GNUStep) from/to arbitrary Go types.

This is packaged as a dependency of CoyIM.

Assado de Tira com Purê de Mandioquinha

[Pague Menos]

html {width: 100%}
body {background-color: #ff; margin: 0px; padding: 0px; font-family: Arial, 
Helvetica, sans-serif;}





 




Caso não esteja visualizando as imagens, acesse aqui








 
 
 
 
 
 
  
  
  
  
  
 
 
 
 
 
 
 
 
 
  
  
  
  
  
 
 
 
 
 
 
 











 

































 



 


 
 C A Caixa Nº: 6-2466/2016 Este é um serviço prestado a 
você pela Rede de Supermercados Pague Menos As ofertas anunciadas neste 
e-mail são válidas até 16/10/2016, enquanto durarem os 
estoques Caso haja diferença de preço ou descrição 
do produto entre este e-mail e o site, a condição válida e 
praticada será a do site As promoções da Rede de 
Supermercados Pague Menos não são cumulativas

As promoções classificadas como “Só Hoje” 
são válidas somente na data de disparo deste e-mail Trata-se de 
um aviso informativo, não significa que você está comprando 
este produto nem tenha feito uma reserva de compra deste item As imagens 
encontradas no e-mail são meramente ilustrativas

Para esclarecer dúvidas ou enviar sugestões, acesse nossa central 
de relacionamento ou escreva para falecom@supermercadospaguemenoscombr ou ligue 
para (19) 3466-8100 – ramal 1009 







 


Não deseja mais receber nossas mensagens? Acesse esse link


 

Re: client-side signature checking of Debian archives (Re: When should we https our mirrors?)

[Adrian Bunk]

On Sun, Oct 23, 2016 at 07:28:23PM -0700, Russ Allbery wrote:
>...
> The value of HTTPS lies in its protection against passive snooping.  Given
> the sad state of the public CA infrastructure, you cannot really protect
> against active MITM with HTTPS without certificate pinning.

You are implicitely assuming that mirrors can be trusted, 
and even that is not true.

Who is operating ftp.cn.debian.org, and who has access to the logfiles 
on that server?

Debian would accept debian.nsa.gov as mirror, and the NSA might already 
operate or have access at some current mirrors.

> But that's
> fine; active attackers are a much, much rarer attack profile.  The most
> likely attack, and the one we're able to protect against here, is passive
> observation of mirror traffic used to build a database of who is using
> what package and at what version.  HTTPS doesn't *prevent* this, but it
> requires the attacker to do much more sophisticated traffic analysis, or
> take the *much* more expensive and *far* riskier step of moving to active
> interference with traffic, neither of which nation-state attackers want to
> do and neither of which they have the resources to do *routinely*.
> 
> It won't help if a nation-state actor is targeting you *in particular*.
> But it helps immensely against dragnet surveillance.

No, it does not help much.

When a nation-state actor analyzes all the traffic on a network 
connection that also happens to carry the traffic between you and
the Debian mirror you are using, HTTPS won't make a difference.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: Keysafe dynamic UID

[W. Martin Borgert]

Quoting Tollef Fog Heen :

I'd prefer if user creation was just done declaratively and then we
could scan the archive.  If we have a manually-maintained list, it will
get out of sync with reality pretty quickly.


+1 and +1
It would be nice to have some progress on this:
https://wiki.debian.org/Teams/Dpkg/Spec/DeclarativePackaging

Re: When should we https our mirrors?

[Kristian Erik Hermansen]

On Mon, Oct 24, 2016 at 1:59 AM, Adrian Bunk  wrote:
> It is a common misconception that https could help against these kinds
> of attacks.
>
> https is an improvement over http and it would be good if Debian could
> switch to https by default in stretch, but for the problem you are
> talking about it does not really make a difference.
>
> https can obfuscate the traffic enough that a casual observer
> has problems determining what exactly is being transferred.
>
> If someone like the NSA is analyzing all your traffic, then the
> information when and how much data gets transferred should be
> sufficient to deduce exactly the information you are worried about.

The point is to make passive analysis more costly to do so. If they
have to assign a probability and it takes exponentially more resources
than simply "save PCAP to disk", then HTTPS has improved the
situation. And again, HTTP/2 can also help to obscure that analysis.
Right now, I only see three Debian mirrors that support HTTP/2 and
they are all in Chinese-speaking locales.

mirrors.tuna.tsinghua.edu.cn
mirrors.ustc.edu.cn
shadow.ind.ntou.edu.tw

> apt-transport-tor is the only option that has a realistic chance of
> helping you, unless you want to run a mirror of Debian in your network.
> Anyone who is seriously worried about these issues and has a clue about
> security will end up doing something like that.

Yes and it is the default in Tails OS. However, it would be prudent to
include a secure default option for everyone else that utilizes Debian
in the future.

> For the kind of attacks you are describing, https is just snake oil.

Profusely disagree and so do other members of this list. I'll leave it
at that, but also I should point out that your email is being routed
insecurely via welho.com and lacks TLS in transit, so I also probably
shouldn't consider your TLS knowledge very highly...

-- 
Regards,

Kristian Erik Hermansen
https://www.linkedin.com/in/kristianhermansen

Re: client-side signature checking of Debian archives (Re: When should we https our mirrors?)

[Kristian Erik Hermansen]

On Mon, Oct 24, 2016 at 2:33 AM, Adrian Bunk  wrote:
> You are implicitely assuming that mirrors can be trusted,
> and even that is not true.

No, not actually. Just presuming that NSA doesn't operate ALL mirrors.
Of course they can operate single servers or a number of servers, but
that increases costs and makes it harder to passively collude against
ALL users.

> Who is operating ftp.cn.debian.org, and who has access to the logfiles
> on that server?
>
> Debian would accept debian.nsa.gov as mirror, and the NSA might already
> operate or have access at some current mirrors.

Right, but that's a much smaller subset of ALL.

> When a nation-state actor analyzes all the traffic on a network
> connection that also happens to carry the traffic between you and
> the Debian mirror you are using, HTTPS won't make a difference.

If it doesn't make a difference, send me a PCAP of all your private
traffic captured from an intermediary node :) I mean, if you don't
seem to care, you won't mind me looking through your stuff. And I also
encourage you to configure your browsers and email clients to utilize
only plaintext HTTP / SMTP / IMAP / POP, perhaps on public wifi too,
so we can all read it. You know, I mean, if it "doesn't make a
difference to you" if you use HTTP or HTTPS or other unencrypted
protocols. The reason it matters so much with SecureAPT is because
these are critical protocols running with root privileges on your
system and are leaking a large amount of data about your system
configuration and the security of it. I don't think I need to belabor
that point. HTTPS does make a huge difference and the entire Internet
would not be using it if "didn't make a difference".

We can probably end the thread here because numerous respected @debian
contributors have confirmed the issues with confidentiality and seem
to making efforts in that direction (hopefully for the next release).

-- 
Regards,

Kristian Erik Hermansen
https://www.linkedin.com/in/kristianhermansen

Re: client-side signature checking of Debian archives

[David Kalnischkies]

(Disclaimer: I am a maintainer of apt-transport-tor… but also of
-https and apt itself, so I am biased beyond hope in this matter)

On Sun, Oct 23, 2016 at 07:20:35PM -0700, Russ Allbery wrote:
> Paul Wise  writes:
> > On Mon, Oct 24, 2016 at 7:21 AM, Kristian Erik Hermansen wrote:
> >> The point is to improve privacy.
> 
> > Better privacy than https can be had using Tor:
> 
> > https://onion.debian.org/
> 
> Yeah, but this is *way* harder than just using TLS.  You get much of the
> benefit by using TLS, and Tor comes with a variety of mildly problematic

TLS doesn't give you a lot of privacy in the context of Debian mirrors.
The traffic analyse Russ has hinted at is one thing, but the biggest
privacy issue is actually that you are a Debian user – and that is
communicated in the clear regardless of using HTTPS or not e.g. if you
connect to security.debian.org. Keeping track of then you connect to
figure out how long it takes you to react to DSAs isn't exactly hard
either. Would it be interesting to know which packages you install?
Maybe if I am really interested in you as it takes ages to get to know
all your packages (if you don't happen to do an upgrade to a new major
release), but as the average evil doer I know more than enough already:
Your IP and that you are likely suspect to recent exploits for at least
a few minutes still. That should be enough to add you to my botnet… (or
lets imagine something "less scary": The bar you are in offering
a special two-for-one-beer for Debian users "out of nowhere"…).


> side effects (speed issues,

Maybe its just me being lucky, but speed seems not to be an issue for me
for apt via Tor. Okay, the initial connect takes slightly longer, but
after that is done apts (tor+)http method with its support of pipelining
is actually perfectly capable of maxing out my connection (regardless of
onion or "normal" mirrors I am connecting to) in most cases.


> rather more complicated to set up and keep
> going for the average person,

No. For the average user its a matter of installing apt-transport-tor
and changing sources.list [if you have ideas/patches to enhance this
further feel free to contact us]. You have to do the same for https.
You don't have to go all Tor for everything at once…

(okay, it gets tricky perhaps if your network is blocking connection to
known Tor nodes at which point you need bridges, but the same network
could forbid [non-MITM] HTTPS, so that argument isn't super strong)

Operating an onion service is a different matter of course, but your
average person isn't very likely to setup a good http (or https) mirror
either and you don't absolutely need an onion service. Your usual http
will do. Sure, all-knowing traffic analyse will be capable of perhaps
figuring out what you do in that case, but that chance is a lot lower
the more traffic is routed through the Tor network and the information
that you are a Debian user isn't clearly written on your connection…
(Your are trading it in for "Tor user" which might or might not be
a better label to have at the moment, but given that we are talking
about people out there trying to get you they probably don't need
additional incentive…)


That said, sure, having https would be cool against the casual MITM like
these pesky login-before-you-can-use-our-free-internet portals, but we
already know that. We don't need yet another person coming here and
trying to convince us that HTTPS is the magic bullet we have all been
waiting for because it isn't. Various people have said for various teams
already which technical challenges need to be solved before we can
seriously think about rolling out https on a broad scale and as usual
the problems aren't fixing themselves if only we talk long enough about
them…


Best regards

David Kalnischkies


signature.asc
Description: PGP signature

when should we esmtps our mxes?

[Ivan Shmakov]

> Kristian Erik Hermansen  writes:
> On Mon, Oct 24, 2016 at 1:59 AM, Adrian Bunk  wrote:

[…]

 >> For the kind of attacks you are describing, https is just snake oil.

 > Profusely disagree and so do other members of this list.  I'll leave
 > it at that, but also I should point out that your email is being
 > routed insecurely via welho.com and lacks TLS in transit, so I also
 > probably shouldn't consider your TLS knowledge very highly…

Speaking of which.  Does the gnutls-cli transcript MIMEd signify
of an ongoing MitM attack, or is it just a misconfiguration?

-- 
FSF associate member #7257  58F8 0F47 53F5 2EB2 F6A5  8916 3013 B6A0 230E 334A
$ dig +nocomment mx lists.debian.org 
…
lists.debian.org.   3600IN  MX  0 bendel.debian.org.
…
$ gnutls-cli --starttls -p 25  bendel.debian.org 
Processed 173 CA certificate(s).
Resolving 'bendel.debian.org'...
Connecting to '2001:41b8:202:deb:216:36ff:fe40:4002:443'...
Connecting to '82.195.75.100:443'...

- Simple Client Mode:

*** Starting TLS handshake
- Certificate type: X.509
- Got a certificate list of 2 certificates.
- Certificate[0] info:
 - subject `C=NA,ST=NA,L=Ankh Morpork,O=Debian SMTP,OU=Debian SMTP 
CA,CN=bendel.debian.org,EMAIL=hostmas...@bendel.debian.org', issuer 
`C=NA,ST=NA,L=Ankh Morpork,O=Debian SMTP,OU=Debian SMTP CA,CN=Debian SMTP 
CA,EMAIL=hostmas...@puppet.debian.org', RSA key 2048 bits, signed using 
RSA-SHA1, activated `2016-02-09 00:00:13 UTC', expires `2017-02-08 00:00:13 
UTC', SHA-1 fingerprint `d99dffbab982a0bbca0f95cf88401f75d75a0194'
Public Key ID:
a6fa6354cd66e04bba4f3c3e5f45bf82afe17b61
Public key's random art:
+--[ RSA 2048]+
| |
|.|
|   . +.  |
|+ =  . . |
|   +S+. .|
|  o+.   .E  .|
| ...+  oo... |
| .+oo..  |
|.o.ooo.++.   |
+-+

- Certificate[1] info:
 - subject `C=NA,ST=NA,L=Ankh Morpork,O=Debian SMTP,OU=Debian SMTP CA,CN=Debian 
SMTP CA,EMAIL=hostmas...@puppet.debian.org', issuer `C=NA,ST=NA,L=Ankh 
Morpork,O=Debian SMTP,OU=Debian SMTP CA,CN=Debian SMTP 
CA,EMAIL=hostmas...@puppet.debian.org', RSA key 2048 bits, signed using 
RSA-SHA1, activated `2009-04-04 22:40:56 UTC', expires `2019-04-02 22:40:56 
UTC', SHA-1 fingerprint `2bd080f1a4c79bae4d8ce3728fd2483b49ce4ca5'
- Status: The certificate is NOT trusted. The certificate issuer is unknown. 
*** PKI verification of server certificate failed...
*** Fatal error: Error in the certificate.
*** Handshake has failed

Re: When should we https our mirrors?

[Adrian Bunk]

On Mon, Oct 24, 2016 at 04:00:49AM -0700, Kristian Erik Hermansen wrote:
> On Mon, Oct 24, 2016 at 1:59 AM, Adrian Bunk  wrote:
> but also I should point out that your email is being routed
> insecurely via welho.com and lacks TLS in transit, so I also probably
> shouldn't consider your TLS knowledge very highly...

Your incorrect claims won't become better by personal attacks against me.

What would TLS protect against when sending an email to a public
mailing list?

The contents (including all headers) is anyway public, and if either
of us was worried about someone modifying the contents of the email
he would add a signature.

> > It is a common misconception that https could help against these kinds
> > of attacks.
> >
> > https is an improvement over http and it would be good if Debian could
> > switch to https by default in stretch, but for the problem you are
> > talking about it does not really make a difference.
> >
> > https can obfuscate the traffic enough that a casual observer
> > has problems determining what exactly is being transferred.
> >
> > If someone like the NSA is analyzing all your traffic, then the
> > information when and how much data gets transferred should be
> > sufficient to deduce exactly the information you are worried about.
> 
> The point is to make passive analysis more costly to do so. If they
> have to assign a probability and it takes exponentially more resources
> than simply "save PCAP to disk", then HTTPS has improved the
> situation.
>...

Against someone like the NSA the improvement is pretty marginal,
and I doubt it would increase the work they have to do much.

Encrypting the contents doesn't help much when you can deduce the 
contents from the timing and amount of the transfers.

Your claims that using https for that purpose would give any kind of 
protections against actors like the NSA are just snake oil.

Pretty dangerous snake oil, if someone ends up believing what you wrote  
instead of using a proper solution like apt-transport-tor.

Debian is an Open Source project, and the only way you can improve 
anything is by doing work yourself - if all you are doing is producing 
hot air, you will achieve nothing.

People have already pointed out several areas where work needs to be 
done for using https by default, and if this is important for you there 
is for example nothing stopping you from starting to work right now on 
improving the https transport in apt.

Or you could prove that it is actually not that important for you by 
doing no development work for that.

Noone is arguing that switching to https would be a bad thing,
but whether or not it will happen depends solely on whether or
not people like you will do the work to make it happen.

> Regards,

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#841913: ITP: gnome-shell-extension-refresh-wifi -- keep wifi access point list current in GNOME shell

[Jonathan Carter]

Package: wnpp
Severity: wishlist
Owner: Jonathan Carter 

* Package name: gnome-shell-extension-refresh-wifi
  Version : 6-1
  Upstream Author : Gopi Sankar Karmegam
* URL : https://github.com/kgshank/gse-refresh-wifi
* License : GPL-3
  Programming Lang: Javascript
  Description : keep wifi access point list current in GNOME shell

By default, GNOME doesn't scan for additional networks once you're
connected to a network.
.
This extension will periodically refresh the wifi list, making it
easier to switch networks.

Re: when should we esmtps our mxes?

[Andrey Rahmatullin]

On Mon, Oct 24, 2016 at 11:45:33AM +, Ivan Shmakov wrote:
> $ gnutls-cli --starttls -p 25  bendel.debian.org 
> Processed 173 CA certificate(s).
> Resolving 'bendel.debian.org'...
> Connecting to '2001:41b8:202:deb:216:36ff:fe40:4002:443'...
> Connecting to '82.195.75.100:443'...
I cannot reproduce gnutls-cli connecting to :443 when asked :25.

> - Certificate[1] info:
>  - subject `C=NA,ST=NA,L=Ankh Morpork,O=Debian SMTP,OU=Debian SMTP 
> CA,CN=Debian SMTP CA,EMAIL=hostmas...@puppet.debian.org', issuer 
> `C=NA,ST=NA,L=Ankh Morpork,O=Debian SMTP,OU=Debian SMTP CA,CN=Debian SMTP 
> CA,EMAIL=hostmas...@puppet.debian.org', RSA key 2048 bits, signed using 
> RSA-SHA1, activated `2009-04-04 22:40:56 UTC', expires `2019-04-02 22:40:56 
> UTC', SHA-1 fingerprint `2bd080f1a4c79bae4d8ce3728fd2483b49ce4ca5'
> - Status: The certificate is NOT trusted. The certificate issuer is unknown. 
I don't think you need  to connect to bendel.debian.org via HTTPS to use
the email.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#841920: ITP: gnome-shell-extension-hide-activities -- gnome shell extension that hides the activities button

[Jonathan Carter]

Package: wnpp
Severity: wishlist
Owner: Jonathan Carter 

* Package name: gnome-shell-extension-hide-activities
  Version : 0.00~git20131024.1.6574986-1
  Upstream Author : Shay Elkin
* URL : https://github.com/shayel/gnome-hide-activities
* License : PD
  Programming Lang: Javascript
  Description : gnome shell extension that hides the activities button

This extension hides the Acitivies text and button on the top left
corner of GNOME shell, making the appearance simpler and the panel
less cluttered.

Re: when should we esmtps our mxes?

[Ivan Shmakov]

> Andrey Rahmatullin  writes:
> On Mon, Oct 24, 2016 at 11:45:33AM +, Ivan Shmakov wrote:

 >> $ gnutls-cli --starttls -p 25 bendel.debian.org 

[…]

 >> Connecting to '82.195.75.100:443'...

 > I cannot reproduce gnutls-cli connecting to :443 when asked :25.

Indeed, my mistake; I somehow managed to MIME the wrong
transcript.  Here’s the correct one.

[…]

-- 
FSF associate member #7257  58F8 0F47 53F5 2EB2 F6A5  8916 3013 B6A0 230E 334A
Processed 173 CA certificate(s).
Resolving 'bendel.debian.org'...
Connecting to '2001:41b8:202:deb:216:36ff:fe40:4002:25'...

- Simple Client Mode:

220 bendel.debian.org ESMTP Postfix
EHLO test 
250-bendel.debian.org
250-PIPELINING
250-SIZE 3072
250-STARTTLS
250-ENHANCEDSTATUSCODES
250 8BITMIME
STARTTLS
220 2.0.0 Ready to start TLS
*** Starting TLS handshake
- Certificate type: X.509
- Got a certificate list of 2 certificates.
- Certificate[0] info:
 - subject `C=NA,ST=NA,L=Ankh Morpork,O=Debian SMTP,OU=Debian SMTP 
CA,CN=bendel.debian.org,EMAIL=hostmas...@bendel.debian.org', issuer 
`C=NA,ST=NA,L=Ankh Morpork,O=Debian SMTP,OU=Debian SMTP CA,CN=Debian SMTP 
CA,EMAIL=hostmas...@puppet.debian.org', RSA key 2048 bits, signed using 
RSA-SHA1, activated `2016-02-09 00:00:13 UTC', expires `2017-02-08 00:00:13 
UTC', SHA-1 fingerprint `d99dffbab982a0bbca0f95cf88401f75d75a0194'
Public Key ID:
a6fa6354cd66e04bba4f3c3e5f45bf82afe17b61
Public key's random art:
+--[ RSA 2048]+
| |
|.|
|   . +.  |
|+ =  . . |
|   +S+. .|
|  o+.   .E  .|
| ...+  oo... |
| .+oo..  |
|.o.ooo.++.   |
+-+

- Certificate[1] info:
 - subject `C=NA,ST=NA,L=Ankh Morpork,O=Debian SMTP,OU=Debian SMTP CA,CN=Debian 
SMTP CA,EMAIL=hostmas...@puppet.debian.org', issuer `C=NA,ST=NA,L=Ankh 
Morpork,O=Debian SMTP,OU=Debian SMTP CA,CN=Debian SMTP 
CA,EMAIL=hostmas...@puppet.debian.org', RSA key 2048 bits, signed using 
RSA-SHA1, activated `2009-04-04 22:40:56 UTC', expires `2019-04-02 22:40:56 
UTC', SHA-1 fingerprint `2bd080f1a4c79bae4d8ce3728fd2483b49ce4ca5'
- Status: The certificate is NOT trusted. The certificate issuer is unknown. 
*** PKI verification of server certificate failed...
*** Fatal error: Error in the certificate.
*** Handshake has failed

Re: when should we esmtps our mxes?

[Julien Cristau]

On Mon, Oct 24, 2016 at 11:45:33 +, Ivan Shmakov wrote:

> > Kristian Erik Hermansen  writes:
> > On Mon, Oct 24, 2016 at 1:59 AM, Adrian Bunk  wrote:
> 
> […]
> 
>  >> For the kind of attacks you are describing, https is just snake oil.
> 
>  > Profusely disagree and so do other members of this list.  I'll leave
>  > it at that, but also I should point out that your email is being
>  > routed insecurely via welho.com and lacks TLS in transit, so I also
>  > probably shouldn't consider your TLS knowledge very highly…
> 
>   Speaking of which.  Does the gnutls-cli transcript MIMEd signify
>   of an ongoing MitM attack, or is it just a misconfiguration?
> 
Neither.

_25._tcp.bendel.debian.org. 3600 IN RRSIG   TLSA 8 5 3600 20161202211237 
20161023203831 7866 debian.org. 
uCQU3vi1LA/bhjW51xETwZn3wWsLPFUvvW4BU1uUE8uJqzsQTdzNBWgW 
+aIE9gOphLZ+zMdni/16QvAV8FWqJ77RZm5RoZFBZ9NbvF/OBgYqlKx/ 
NpR79goHcI6NHMezAh6BF3PEE3gQjogAXlA9pLhf8hVyQh117sLHyVPt 
sc/d+mJv9CTCiwSUqiG/e3V0je2dt7SpIcI+uxDL/pe/6dt3qSOE5hpH 
xtvG1xaoYcF1UWGMP12j8LIK2V+sNRbq
_25._tcp.bendel.debian.org. 3600 IN TLSA3 1 1 
7D8AC6B95A22EFBE727768523798BC914AFA9F22A10F7847023E2D8A B982D234

Cheers,
Julien

Re: when should we esmtps our mxes?

[Ben Hutchings]

On Mon, 2016-10-24 at 13:00 +, Ivan Shmakov wrote:
> > 
> > Andrey Rahmatullin  writes:
> > On Mon, Oct 24, 2016 at 11:45:33AM +, Ivan Shmakov wrote:
> 
> 
>  >> $ gnutls-cli --starttls -p 25 bendel.debian.org 
> 
> […]
> 
>  >> Connecting to '82.195.75.100:443'...
> 
>  > I cannot reproduce gnutls-cli connecting to :443 when asked :25.
> 
>   Indeed, my mistake; I somehow managed to MIME the wrong
>   transcript.  Here’s the correct one.
[...]

Those certificates look as expected.  Since TLS encryption of SMTP
between servers is opportunistic, there's no particular reason to use a
widely trusted CA for server certificates.  A MITM can just as easily
block STARTTLS as substitute their own key.

Ben.

-- 
Ben Hutchings
For every complex problem
there is a solution that is simple, neat, and wrong.



signature.asc
Description: This is a digitally signed message part

Re: When should we https our mirrors?

[Ian Jackson]

Adrian Bunk writes ("Re: When should we https our mirrors?"):
> On Mon, Oct 24, 2016 at 04:00:49AM -0700, Kristian Erik Hermansen wrote:
> >  so I also probably
> > shouldn't consider your TLS knowledge very highly...
> 
> Your incorrect claims won't become better by personal attacks against me.

Can we please terminate this whole subthread ?

It seems to me that consensus is that using TLS for apt would be an
improvement.

There is of course room for dispute about exactly how much of an
improvement and precisely what kind of attacks it may help against,
but I don't think we are going to come up with an answer to that kind
of question on debian-devel.  (Not least because the real answer -
"how valuable is it" - is very hard to quantify in a meaningful way.)

It is also evident that there are some challenges for deploying TLS on
a mirror network and/or CDN.  I don't think anyone is suggesting
tearing down our existing mirror network.

It is fair of people to raise the question: have we considered this
and here are some reasons why it might be valuable ?  This has already
resulted in some improvement.  It is also fair of people who care
abouit this to raise the issue by way of encouragement.  If not
everything they say is 100% cast-iron truth that does not necessarily
need to be challenged, if we by and large agree with the thrust of the
argument and the intended goals.

Posting such a message is also a way to find out who to contact, find
out what the problems are, so that people who want to make the use of
TLS more widespread can know how, in practice, they can help.


Adrian:
> Noone is arguing that switching to https would be a bad thing,
> but whether or not it will happen depends solely on whether or
> not people like you will do the work to make it happen.

I think there is a problem with messages like your earlier one:

 | It is a common misconception that https could help against these
 | kinds of attacks.
 ...
 | For the kind of attacks you are describing, https is just snake
 | oil.

It is very difficult for someone who disagrees with that to let it
slide.  I don't understand why you thought it valuable to put forward
that position so strongly.  I'm afraid that your messages so far have
come across as picking an unnecessary fight with Kristian, while
simultaneously blaming Kristian for continuing the argument.

I would have suggested writing something more like this:

 ] I agree that https is an improvement over http and it would be good
 ] if Debian could switch to https by default in stretch.
 ]
 ] (This is despite the fact that I don't necessarily agree that https
 ] helps significantly against the attacks you describe.  But I don't
 ] think we really need to have that argument.)
 ]
 ] I encourage you to work with the relevant people on the technical
 ] aspects of increasing the use of TLS by apt.  They could probably
 ] do with your help.


OTOH, Kristian, I agree with Adrian that your comments about
"shouldn't consider your TLS knowledge very highly" are inflammatory
and inappropriate.


Thanks,
Ian.

-- 
Ian JacksonThese opinions are my own.

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

Re: when should we esmtps our mxes?

[Ivan Shmakov]

> Julien Cristau  writes:
> On Mon, Oct 24, 2016 at 11:45:33 +, Ivan Shmakov wrote:

[…]

 >> Speaking of which.  Does the gnutls-cli transcript MIMEd signify of
 >> an ongoing MitM attack, or is it just a misconfiguration?

 > Neither.

 > _25._tcp.bendel.debian.org. 3600 IN RRSIG TLSA 8 5 3600
 > 20161202211237 20161023203831 7866 debian.org.
 > uCQU3vi1LA/bhjW51xETwZn3wWsLPFUvvW4BU1uUE8uJqzsQTdzNBWgW
 > +aIE9gOphLZ+zMdni/16QvAV8FWqJ77RZm5RoZFBZ9NbvF/OBgYqlKx/
 > NpR79goHcI6NHMezAh6BF3PEE3gQjogAXlA9pLhf8hVyQh117sLHyVPt
 > sc/d+mJv9CTCiwSUqiG/e3V0je2dt7SpIcI+uxDL/pe/6dt3qSOE5hpH
 > xtvG1xaoYcF1UWGMP12j8LIK2V+sNRbq

 > _25._tcp.bendel.debian.org. 3600 IN TLSA 3 1 1
 > 7D8AC6B95A22EFBE727768523798BC914AFA9F22A10F7847023E2D8A B982D234

Makes sense, thanks.

Although I gather I won’t be seeing it actually working with my
MX anytime soon.

-- 
FSF associate member #7257  58F8 0F47 53F5 2EB2 F6A5  8916 3013 B6A0 230E 334A

Re: when should we esmtps our mxes?

[Ivan Shmakov]

> Ben Hutchings  writes:

[…]

 > Those certificates look as expected.  Since TLS encryption of SMTP
 > between servers is opportunistic, there's no particular reason to use
 > a widely trusted CA for server certificates.  A MITM can just as
 > easily block STARTTLS as substitute their own key.

That’s not necessarily any different to the HTTP(S) case.

For instance, when the user first uses ‘example.com’ as the
resource identifier, the Web user agent (usually) issues a GET
request to the said host’s HTTP server in the plain.  At which
point the server responds with a 302 redirect, pointing to the
resource proper (say, https://example.com/.)

That behavior is hardly any less opportunistic, and is prone to
the very same attack, as demonstrated by ‘sslstrip’.

Yet, I’d find that quite an uncommon reason to argue that we
don’t need some widely trusted CAs for the HTTPS certificates.

On the other hand, my MX setup relies on ‘exim4/relay_tls_dn’
files that contain the list of CNs of the remotes the MTA
permits relaying mail from (that is: acts as a smarthost for.)
Hence, TLS becomes rather mandatory in this case.  (Although I
have to admit that I don’t currently apply this approach in the
“downstream” direction with any consistency.)

-- 
FSF associate member #7257  58F8 0F47 53F5 2EB2 F6A5  8916 3013 B6A0 230E 334A

Re: When should we https our mirrors?

[Paul Tagliamonte]

On Mon, Oct 24, 2016 at 04:00:39PM +0100, Ian Jackson wrote:
> It is also evident that there are some challenges for deploying TLS on
> a mirror network and/or CDN.  I don't think anyone is suggesting
> tearing down our existing mirror network.

https://deb.debian.org/ is now set up (thanks, folks!), so my attention
is now shifted away from the push to https all the things (not everyone
will, so I just want a stable well-used domain that could be a sensable
default, and let those who don't want to move forward stay in the past)
and on to considering the apt https transport and thoughts on how this
could become part of the base install.

I'm trying to think up some arguments for and against a few good points
before I distract this thread with more about that.

Cheers,
  Paul


signature.asc
Description: PGP signature

Re: When should we https our mirrors?

[Adrian Bunk]

On Mon, Oct 24, 2016 at 04:00:39PM +0100, Ian Jackson wrote:
> Adrian Bunk writes ("Re: When should we https our mirrors?"):
>...
> Adrian:
> > Noone is arguing that switching to https would be a bad thing,
> > but whether or not it will happen depends solely on whether or
> > not people like you will do the work to make it happen.
> 
> I think there is a problem with messages like your earlier one:
>
>  | It is a common misconception that https could help against these
>  | kinds of attacks.
>  ...
>  | For the kind of attacks you are describing, https is just snake
>  | oil.
> 
> It is very difficult for someone who disagrees with that to let it
> slide.  I don't understand why you thought it valuable to put forward
> that position so strongly. I'm afraid that your messages so far have
> come across as picking an unnecessary fight with Kristian,

In the email I replied to, Kristian did write:
  I am sure everyone here is much smarter than me, so I am looking for
  some feedback on this.

Kristian was not asking for how he could contribute to Debian.

Kristian was asking for feedback on what he described.

I gave feedback.

> while
> simultaneously blaming Kristian for continuing the argument.

Where did I blame Kristian for continuing the argument?
 
> I would have suggested writing something more like this:
> 
>  ] I agree that https is an improvement over http and it would be good
>  ] if Debian could switch to https by default in stretch.
>  ]
>  ] (This is despite the fact that I don't necessarily agree that https
>  ] helps significantly against the attacks you describe.  But I don't
>  ] think we really need to have that argument.)

This is not about agreeing on the favorite ice cream flacour.

My point is that for the problem Kristian is describing,
using https is just snake oil.

apt-transport-https is not a solution for this problem,
if this problem should be solved you need apt-transport-tor.

This global picture should be clear to everyone.

https by default should be doable and would be non-controversial,
but it would be a lot of work for relatively small benefit.

And it would not solve this problem.

If the goal is to solve this problem, a solution might for example be
to make apt-transport-tor more visible.

>  ] I encourage you to work with the relevant people on the technical
>  ] aspects of increasing the use of TLS by apt.  They could probably
>  ] do with your help.
> 
> OTOH, Kristian, I agree with Adrian that your comments about
> "shouldn't consider your TLS knowledge very highly" are inflammatory
> and inappropriate.
> 
> 
> Thanks,
> Ian.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: client-side signature checking of Debian archives (Re: When should we https our mirrors?)

[Russ Allbery]

Adrian Bunk  writes:
> On Sun, Oct 23, 2016 at 07:28:23PM -0700, Russ Allbery wrote:

>>...
>> The value of HTTPS lies in its protection against passive snooping.  Given
>> the sad state of the public CA infrastructure, you cannot really protect
>> against active MITM with HTTPS without certificate pinning.

> You are implicitely assuming that mirrors can be trusted, 
> and even that is not true.

> Who is operating ftp.cn.debian.org, and who has access to the logfiles 
> on that server?

So, here, I think you're making the best the enemy of the good, which is
always tempting in security.

Everyone (myself included) wants to create a system that's actually
secure, the same way that we want to create software that works properly.
But in security, even more so than most software, that's rarely possible.
There's always another attack.  It's a sliding scale of tradeoffs, and
just because you're not preventing all attacks doesn't mean that making
things harder for the attacker isn't useful.

Looking at this worry in particular, note that you're now assuming that a
nation-state has compromised a specific mirror (in some way, maybe just by
running it without regard to the privacy of its users).  As pointed out,
this only gets partial information, but more importantly, this requires
the nation-state to actively do something.  They have to now either
compromise the mirror or be running it in a way that may be discoverable.

Security is both technical and politics, and on the political side,
actively doing something is much riskier.  Nation-state surveillance teams
are generally not fond of headlines, and there are political consequences
to being caught with your hand in the cookie jar.  Therefore, technical
measures that force them to take an *active* measure to get data, as
opposed to just passively tapping and siphoning data, are, in practice,
quite effective.  Not because they don't have the technical capabilities
to do that, but because it's much riskier politically to do so, and often
that risk isn't worth the reward from their perspective.

It's true that tapping a single mirror could still be passive, but it's a
much trickier kind of passive than just snooping on a cable.  They have to
be passively collecting the actual server logs in some way, which means
presence on the box or access to some network where those logs are being
sent in the clear.  That does raise the bar substantially.

> Debian would accept debian.nsa.gov as mirror, and the NSA might already 
> operate or have access at some current mirrors.

I'm a little dubious that this is true (I would recommend against it), but
even if so, Debian could also easily revoke that acceptance at any point
if we decided we were uncomfortable with it, which makes it an unreliable
way to gather this sort of data.

> When a nation-state actor analyzes all the traffic on a network
> connection that also happens to carry the traffic between you and the
> Debian mirror you are using, HTTPS won't make a difference.

Well, I disagree, largely because I think you're overestimating the
willingness to do deep data analysis on something that's only a tertiary
(at best) security objective.

Dragnet surveillance is the most common nation-state approach at the
moment primarily because it's *really easy*.  Get a backbone tap
somewhere, dredge all the unencrypted data, run simple analysis across it
(pulling out URLs accessed is obviously trivial for unencrypted HTTP),
throw it into some sort of huge database, and decide what you want to
query for later.

Doing traffic analysis that requires analyzing encrypted data by object
size or the like is still certainly *possible* (that was the point that I
made in my first message to this thread), but it's not *trivial*.  It
requires someone go write code, go think about the problem, and regularly
gather information from a mirror to correlate encrypted object sizes with
packages.  It requires a *human* actually *think* about the problem, and
then set up and maintain an automated system that requires some level of
ongoing babysitting.

Can nation-states do this?  Obviously, yes.  But the goal here isn't to
prevent them from launching these sorts of attacks.  The goal is to make
it expensive, to require that they justify a budget to hire people to do
all this additional work that requires custom automation, and to raise the
bar across the board to make simplistic dragnet surveillance unrewarding.
This forces them into making some hard decisions about resource allocation
and attempting more visible intrusions.  Hard decisions are expensive, not
just in resources but also in politics.

It *is* a tradeoff, not perfect security, so we should obviously also take
into account how much effort it takes on our side and whether we're
expending less effort than we're forcing from our adversary.  But, in
general, ubiquitous encryption is totally worth it from that sort of
effort analysis.  Once you get good systems in place (Let's Encrypt
seriously

awesome, it's done! (Re: When should we https our mirrors?)

[Holger Levsen]

On Mon, Oct 24, 2016 at 11:51:00AM -0400, Paul Tagliamonte wrote:
> https://deb.debian.org/ is now set up (thanks, folks!)

whoohooo, & it works on stable too! apt install apt-transport-https was
all it took. (and changing the entries in sources.list to that…)

Just security.d.o (or rather, it's suites) are not available via https yet…

but still, very nice! thanks to everyone involved making this happen!


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Re: Bug#820036: No bug mentioning a Debian KEK and booting use it.

[Theodore Ts'o]

On Tue, Oct 18, 2016 at 07:52:13PM +0800, Paul Wise wrote:
> 
> It was posted to bug #820036, which is tracking Debian support for
> secure boot. Peter was advocating quite correctly that as well as
> having our copy of shim (the first-stage bootloader on secure boot
> systems) signed by Microsoft, we should also have a copy signed by a
> Debian signing authority, so that users can theoretically choose to
> distrust the Microsoft key. IIRC, unfortunately in practice that is
> unlikely to be possible since various firmware blobs are only
> Microsoft-signed.

It's probably not possible for Debian to deal with this, but I could
imagine a user (perhaps someone who is using Debian for their entire
organization, etc.) who is willing to download firmware blobs from a
trusted source (e.g., directly from the vendor), and then verify the
Microsoft signature as a double check, and then resign it with their
own signing authority key.

To the extent that we could easily support this particular use case,
it might be a good thing.  (I doubt Debian is going to want to get
into the business of verifying and then resigning firmware blobs.)

Cheers,

- Ted

Re: awesome, it's done! (Re: When should we https our mirrors?)

[Ansgar Burchardt]

On Mon, 2016-10-24 at 16:30 +, Holger Levsen wrote:
> On Mon, Oct 24, 2016 at 11:51:00AM -0400, Paul Tagliamonte wrote:
> > https://deb.debian.org/ is now set up (thanks, folks!)
> 
> whoohooo, & it works on stable too! apt install apt-transport-https
> was
> all it took. (and changing the entries in sources.list to that…)
> 
> Just security.d.o (or rather, it's suites) are not available via
> https yet…
> 
> but still, very nice! thanks to everyone involved making this happen!

deb.debian.org has a debian-security area, so security updates should
also be available via https:// now.

Ansgar

Re: when should we esmtps our mxes?

[Ben Hutchings]

On Mon, 2016-10-24 at 15:15 +, Ivan Shmakov wrote:
> > > > > > 
> > 
> > Ben Hutchings  writes:
> 
> 
> […]
> 
>  > Those certificates look as expected.  Since TLS encryption of SMTP
>  > between servers is opportunistic, there's no particular reason to use
>  > a widely trusted CA for server certificates.  A MITM can just as
>  > easily block STARTTLS as substitute their own key.
> 
>   That’s not necessarily any different to the HTTP(S) case.
> 
>   For instance, when the user first uses ‘example.com’ as the
>   resource identifier, the Web user agent (usually) issues a GET
>   request to the said host’s HTTP server in the plain.  At which
>   point the server responds with a 302 redirect, pointing to the
>   resource proper (say, https://example.com/.)
> 
>   That behavior is hardly any less opportunistic, and is prone to
>   the very same attack, as demonstrated by ‘sslstrip’.

Although that's mitigated by HSTS and bookmarking of https: URLs.

>   Yet, I’d find that quite an uncommon reason to argue that we
>   don’t need some widely trusted CAs for the HTTPS certificates.
> 
>   On the other hand, my MX setup relies on ‘exim4/relay_tls_dn’
>   files that contain the list of CNs of the remotes the MTA
>   permits relaying mail from (that is: acts as a smarthost for.)
>   Hence, TLS becomes rather mandatory in this case.  (Although I
>   have to admit that I don’t currently apply this approach in the
>   “downstream” direction with any consistency.)

Of course you can do this on a smarthost; I do the same.  I don't see
how that's relevant to lists.debian.org.

Ben.

-- 
Ben Hutchings
For every complex problem
there is a solution that is simple, neat, and wrong.



signature.asc
Description: This is a digitally signed message part

Re: When should we https our mirrors?

[Ian Jackson]

Adrian Bunk writes ("Re: When should we https our mirrors?"):
> My point is that for the problem Kristian is describing,
> using https is just snake oil.

Since you haven't stopped being rude just because I asked, I have
emailed listmaster.

Russ's recent posting is a useful contribution to the substantive
question.  I agree with it entirely.  But as I say I don't think we
need to resolve this.

I'm glad to see that people are making https more available and I look
forward to seeing it being more widely used by apt.

Ian.

-- 
Ian JacksonThese opinions are my own.

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

Re: awesome, it's done! (Re: When should we https our mirrors?)

[Holger Levsen]

On Mon, Oct 24, 2016 at 06:52:41PM +0200, Ansgar Burchardt wrote:
> deb.debian.org has a debian-security area, so security updates should
> also be available via https:// now.

yes, they are, thanks!


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Re: When should we https our mirrors?

[Tollef Fog Heen]

]] Paul Tagliamonte 

> On Mon, Oct 24, 2016 at 04:00:39PM +0100, Ian Jackson wrote:
> > It is also evident that there are some challenges for deploying TLS on
> > a mirror network and/or CDN.  I don't think anyone is suggesting
> > tearing down our existing mirror network.
> 
> https://deb.debian.org/ is now set up (thanks, folks!), so my attention
> is now shifted away from the push to https all the things (not everyone
> will, so I just want a stable well-used domain that could be a sensable
> default, and let those who don't want to move forward stay in the past)
> and on to considering the apt https transport and thoughts on how this
> could become part of the base install.

Note that the performance of HTTPS there is worse than for HTTP due to a
lack of SRV support in apt-transport-https, though, which means it falls
back to doing HTTP redirects.

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

Re: Bug#841851: ITP: bind-key -- simple way to manage personal keybindings

[Sean Whitton]

Dear Lev,

On Mon, Oct 24, 2016 at 09:55:50AM +0500, Lev Lamberov wrote:
> (3) users will rather see their elpa-{bind-key,use-package}
> counterparts

I don't understand this reasoning.

The source package name is based on upstream's project name.  The elpa
package name is based on the package.el package name.

E.g. src:aggressive-indent-mode builds bin:elpa-aggressive-indent (no '-mode').

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#841943: ITP: bootstrap-datetimepicker -- Date/time picker widget based on twitter bootstrap

[Michael Fladischer]

Package: wnpp
Severity: wishlist
Owner: Michael Fladischer 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: bootstrap-datetimepicker
  Version : 4.17.43
  Upstream Author : Jonathan Peterson
* URL : https://github.com/Eonasdan/bootstrap-datetimepicker
* License : Expat
  Programming Lang: JS, CSS
  Description : Date/time picker widget based on twitter bootstrap

 This component consists actually of 2 subcomponent UI widgets. One for the date
 and one for the time selection process. The developers can configure which of
 those are needed and also the granularity that the component will allow the
 users to select a date/time. Developers also choose the format that the
 selected datetime will be displayed in the input field. The component uses on
 jQuery, moment.js and bootstrap libraries.

-BEGIN PGP SIGNATURE-

iQEuBAEBCgAYBQJYDkSXERxmbGFkaUBkZWJpYW4ub3JnAAoJEP/TyIuZfdFql/MH
/0uYrprN5i/dckT9FkeoA2hlVWwyC/sHJneH5u5N6n+Vxm/VOLsD+xQesEhK9L4J
nFfUQHEw6zwWCPF/6hG2HlJn8vk9e30BiKLs5/XlQOrW+LnzhAx9mUK6iZUCBZS0
8q5hN4KhiS28RcqzFCS/s1esjafIX/L2P75IKA+5CY/vXyA5aQ7ZYyfE6upWHA/c
Lgnrk/tAMiTD1bYRaryf0D/vqBq/T4yMrTYEl8kmBUtSeQty1PFnpWpuTyYF/pZP
wNS+2fRvn5c8hqwuwaMM26ityoxeamkZwTwM4dIZjX0dBLTIe4U1KJHv7Xtxf1JW
sll9my0SrGr0OIik2OvKnKQ=
=WKRb
-END PGP SIGNATURE-

Re: Keysafe dynamic UID

[Sean Whitton]

On Mon, Oct 24, 2016 at 08:58:49AM +0200, Christian Seiler wrote:
> The requirement to have this for dynamically allocated IDs also
> probably stems from the fact that the users created in postinst scripts
> should not conflict. But wouldn't it be far easier to just create a
> page on the Debian Wiki and track that there? [1] And have policy say
> to check that list to see that it's unique and add your package + user
> there when you are about to upload a new package? That way, in 99.9% of
> cases where users are required, and they don't conflict with existing
> ones, there's no additional work for people other than the package
> maintainer, and the package maintainer doesn't have to wait for a
> response before they are able to proceed. And if there really is a
> conflict, people can still post to -devel about it.

Probably best to continue this discussion in #841877.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Bug#841852: Bug#841851: ITP: bind-key -- simple way to manage personal keybindings

[Lev Lamberov]

Hi Sean,


24.10.2016 22:27, Sean Whitton пишет:
> Dear Lev,
>
> On Mon, Oct 24, 2016 at 09:55:50AM +0500, Lev Lamberov wrote:
>> (3) users will rather see their elpa-{bind-key,use-package}
>> counterparts
> I don't understand this reasoning.

I don't get what you don't understand.

1. use-package is an upstream project name;
2. bind-key and use-pacakge are package.el package names.

So, in this case:

src:use-package builds bin:elpa-use-package
src:bind-key build bin:elpa-bind-key

What's the question?

Regards,
Lev

signature checking in libcupt (Re: client-side signature checking of Debian archives (Re: When should we https our mirrors?))

[Eugene V. Lyubimkin]

Hi Kristian,

To one of your side questions,

On 24.10.2016 02:33, Kristian Erik Hermansen wrote:
>> 1) Checking chain (e.g. gpgv and its callers) have bugs. True, same as 
>> checking layer for secure transports also have bugs.
> 
> Agreed. Please let me know of a good test case to validate that your
> tools, which are not APT (?), are doing the right things. You said you
> maintained a tool which "downloads and validates Debian archives in a
> similar way APT does", which means not exactly the way APT does. Let
> me know the name of your tool and how to setup some test cases to
> validate your tool is doing things properly. Glad to spend some time
> on it and contribute any potential findings for the community benefit.

The tool I maintain is minor, not widely used package manager, which may or may 
not be worth your time. It's called
Cupt, the sources are at [1a] or [1b]; namely, the checking code at [2] and 
tests for common situations at [3]. One can
play with those test cases, or install the tool and point it [4] to malicious 
servers.

There might be other packages in Debian which access repos not through libapt.


[1a] 
https://alioth.debian.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=cupt/cupt.git;a=tree
[1b] https://github.com/jackyf/cupt
[2] cpp/lib/src/internal/cachefiles.cpp:verifySignature()
[3] test/t/query/repo-signatures/*
[4] same as APT, via /etc/apt/sources.list

Re: When should we https our mirrors?

[David Kalnischkies]

On Mon, Oct 24, 2016 at 07:26:37PM +0200, Tollef Fog Heen wrote:
> ]] Paul Tagliamonte 
> > On Mon, Oct 24, 2016 at 04:00:39PM +0100, Ian Jackson wrote:
> > > It is also evident that there are some challenges for deploying TLS on
> > > a mirror network and/or CDN.  I don't think anyone is suggesting
> > > tearing down our existing mirror network.
> > 
> > https://deb.debian.org/ is now set up (thanks, folks!), so my attention
> > is now shifted away from the push to https all the things (not everyone
> > will, so I just want a stable well-used domain that could be a sensable
> > default, and let those who don't want to move forward stay in the past)
> > and on to considering the apt https transport and thoughts on how this
> > could become part of the base install.
> 
> Note that the performance of HTTPS there is worse than for HTTP due to a
> lack of SRV support in apt-transport-https, though, which means it falls
> back to doing HTTP redirects.

(as apt-transport-https is mentioned I have to comment again…)

It should be only one redirect with apt >= stretch for indexes. For the
*.debs its a redirect each. APT doesn't store redirects between runs as
its hard to keep that current and authoritative (obvious for http,
slightly less obvious for https perhaps).

The SRV support needs to be implemented in (lib)curl as I wouldn't feel
to comfortable working around this [0]. Or, well, implement TLS in apt
directly, but I already mentioned how likely I think that is, but if
anyone wants to try…

And as already mentioned pipeline support in a-t-https would be nice if
someone feels like implementing it via curls multi-interface.

If someone is exceptionally bored we could implement an opportunistic use
of https if a-t-https is installed and "_https._tcp." srv-lookups get
a favorable response by letting http ask for that first and internally
redirect in that case.

So, you see, as usually, there isn't a shortage on ideas. If someone
wants to work on any feel free to join deity@ and/or #debian-apt.


Best regards

David Kalnischkies

[0] which isn't exactly easy and could only be considered a hack as you
can't take over resolving for curl, you could just misuse a facility for
DNS caching to feed it an IP, but you first need to establish that this
IP and port can be connected to, disconnect and hope a "reconnect" in
curl will be equally successful later on as making sense of error codes
isn't exactly easy either…


signature.asc
Description: PGP signature

FTP Master move, second try | Upload queue

[Joerg Jaspert]

Hi

first a short announce: Saturday (that is, 29th of October) we give it
another shot of moving the ftp-master host, so expect another bit of
downtime there.

More importantly: With the changes to the upload queues I announced just
yesterday, we turned off ftpd on the ftp-master host. Anyone who has an
upload config snippet trying to upload there - please adjust to
ftp.upload.debian.org!

-- 
bye, Joerg

Bug#841976: ITP: puppet-module-camptocamp-kmod -- Puppet module for managing kmod configuration

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: puppet-module-camptocamp-kmod
  Version : 2.1.1
  Upstream Author : Raphaël Pinson 
* URL : https://github.com/camptocamp/puppet-kmod
* License : Apache-2.0
  Programming Lang: Puppet
  Description : Puppet module for managing kmod configuration

 Puppet lets you centrally manage every important aspect of your system using a
 cross-platform specification language that manages all the separate elements
 normally aggregated in different files, like users, cron jobs, and hosts,
 along with obviously discrete elements like packages, services, and files.
 .
 This module handles kernel module loading and configuration. It is perfect for
 manipulating things in /etc/modprobe.d/.conf.

Bug#841978: ITP: opcua-client-gui -- simple OPC-UA GUI client

[W. Martin Borgert]

Package: wnpp
Severity: wishlist
Owner: "W. Martin Borgert" 

* Package name: opcua-client-gui
  Version : 0.4.5
  Upstream Author : Olivier Roulet-Dubonnet 
* URL : https://github.com/FreeOpcUa/opcua-client-gui
* License : GPL3
  Programming Lang: Python
  Description : simple OPC-UA GUI client

Basic functionalities are implemented including subscribing for
data changes and events, write variable values, listing attributes
and references.

Note: This program depends on opcua-widgets
(https://github.com/FreeOpcUa/opcua-widgets).

Re: client-side signature checking of Debian archives (Re: When should we https our mirrors?)

[Adrian Bunk]

On Mon, Oct 24, 2016 at 09:22:39AM -0700, Russ Allbery wrote:
> Adrian Bunk  writes:
> > On Sun, Oct 23, 2016 at 07:28:23PM -0700, Russ Allbery wrote:
> 
> >>...
> >> The value of HTTPS lies in its protection against passive snooping.  Given
> >> the sad state of the public CA infrastructure, you cannot really protect
> >> against active MITM with HTTPS without certificate pinning.
> 
> > You are implicitely assuming that mirrors can be trusted, 
> > and even that is not true.
> 
> > Who is operating ftp.cn.debian.org, and who has access to the logfiles 
> > on that server?
> 
> So, here, I think you're making the best the enemy of the good, which is
> always tempting in security.
> 
> Everyone (myself included) wants to create a system that's actually
> secure, the same way that we want to create software that works properly.
> But in security, even more so than most software, that's rarely possible.
> There's always another attack.  It's a sliding scale of tradeoffs, and
> just because you're not preventing all attacks doesn't mean that making
> things harder for the attacker isn't useful.
> 
> Looking at this worry in particular, note that you're now assuming that a
> nation-state has compromised a specific mirror (in some way, maybe just by
> running it without regard to the privacy of its users).  As pointed out,
> this only gets partial information, but more importantly, this requires
> the nation-state to actively do something.  They have to now either
> compromise the mirror or be running it in a way that may be discoverable.
>...

The government operating or having access to the mirror you are using is 
a lot more realistic and easier than the MITM with a fake certificate 
you were talking about.

> > When a nation-state actor analyzes all the traffic on a network
> > connection that also happens to carry the traffic between you and the
> > Debian mirror you are using, HTTPS won't make a difference.
> 
> Well, I disagree, largely because I think you're overestimating the
> willingness to do deep data analysis on something that's only a tertiary
> (at best) security objective.
> 
> Dragnet surveillance is the most common nation-state approach at the
> moment primarily because it's *really easy*.  Get a backbone tap
> somewhere, dredge all the unencrypted data, run simple analysis across it
> (pulling out URLs accessed is obviously trivial for unencrypted HTTP),
> throw it into some sort of huge database, and decide what you want to
> query for later.

Pulling out the dates and amounts transferred fot HTTP traffic is
also trivial.

> Doing traffic analysis that requires analyzing encrypted data by object
> size or the like is still certainly *possible* (that was the point that I
> made in my first message to this thread), but it's not *trivial*.  It
> requires someone go write code, go think about the problem, and regularly
> gather information from a mirror to correlate encrypted object sizes with
> packages.  It requires a *human* actually *think* about the problem, and
> then set up and maintain an automated system that requires some level of
> ongoing babysitting.

I would assume this can be pretty automated, and that by NSA standards 
this is not a hard problem.

> Can nation-states do this?  Obviously, yes.  But the goal here isn't to
> prevent them from launching these sorts of attacks.  The goal is to make
> it expensive, to require that they justify a budget to hire people to do
> all this additional work that requires custom automation, and to raise the
> bar across the board to make simplistic dragnet surveillance unrewarding.
> This forces them into making some hard decisions about resource allocation
> and attempting more visible intrusions.  Hard decisions are expensive, not
> just in resources but also in politics.
> 
> It *is* a tradeoff, not perfect security, so we should obviously also take
> into account how much effort it takes on our side and whether we're
> expending less effort than we're forcing from our adversary.  But, in
> general, ubiquitous encryption is totally worth it from that sort of
> effort analysis.  Once you get good systems in place (Let's Encrypt
> seriously changed the calculation here), adding encryption is usually far
> easier than the work required on the snooping side to recover the sort of
> metadata they had access to unencrypted.  I think that's the case here.

Let me try to summarize my point:

apt-transport-https makes it slightly harder to determine what packages 
are being transferred, and this is good.

When someone is seriously worried about a nation-state actor determining 
what packages he downloads then apt-transport-https is not a solution, 
and the proper solution is apt-transport-tor.

I assume you will disagree regarding the word "slightly".
Are we in agreement regarding the rest of my summary?


When someone is worried about the confidentiality of the information 
what packages are installed on a system, only looking at the download 
side

Re: client-side signature checking of Debian archives (Re: When should we https our mirrors?)

[Russ Allbery]

Adrian Bunk  writes:

> The government operating or having access to the mirror you are using is
> a lot more realistic and easier than the MITM with a fake certificate
> you were talking about.

Both of those were also in the category of things that I think are
unlikely attacks unless the government is specifically targeting you, so
that leaves me confused by what point you're trying to make here.

For the record, MITM with a fake certificate is certainly realistic for a
targeted attack, and is something that one has to think about.  There's a
reason why certificate pinning is a standard part of the defenses in a
higher-security SSL configuration.  I do agree (and in fact this was my
whole point) that it's unlikely a government would burn their certificate
capability this way just to figure out what Debian packages you're
downloading, though.

> I would assume this can be pretty automated, and that by NSA standards
> this is not a hard problem.

Since the entire exchange is encrypted, it's not completely trivial to map
size of data transferred to a specific package (of course, it's even
harder if we reuse connections).  But the point I'm making is more that
it's not something that just falls out of an obvious surveillance
technique that has wide-ranging uses.  It requires someone to write code
to *specifically* target Debian mirrors, which I think is much less likely
than just collecting all the data and deciding to analyze it afterwards.

(That said, it would be possible to reconstruct the necessary data to do
the analysis later, I suppose.  But here too someone has to care at a
level deep enough to go write code to do it, as opposed to just doing ad
hoc queries.)

> Let me try to summarize my point:

> apt-transport-https makes it slightly harder to determine what packages 
> are being transferred, and this is good.

> When someone is seriously worried about a nation-state actor determining 
> what packages he downloads then apt-transport-https is not a solution, 
> and the proper solution is apt-transport-tor.

> I assume you will disagree regarding the word "slightly".
> Are we in agreement regarding the rest of my summary?

I disagree that either of them is a solution.  They're both mitigations,
and if a nation-state attacker is targeting you specifically, I wouldn't
want to rely entirely on either of them.

I agree with you that Tor is a stronger mitigation.

Tor is easier for us as a project, since we don't really have to do
anything (assuming we just rely on existing exit nodes).  SSL is much
harder for us as a project, but is simpler for the end user (and doesn't
require them to take a stance on the merits of Tor as a project; I don't
really want to get into a philosophical argument about the merits of
Internet anonymity, but this is not something everyone thinks is an ideal
to strive for as opposed to a situational fix for very specific risks).
In an ideal world we'd offer both.

> When someone is worried about the confidentiality of the information 
> what packages are installed on a system, only looking at the download 
> side is also missing other areas that might be even more problematic.

This is true.  But the set of problems are largely independent.  While
solving the download side doesn't fix all the other problems, it also
doesn't interfere with fixing all the other problems, and is still needed
to make the overall system more secure.

The reason why addressing the download side is appealing to me is that we
know dragnet surveillance is common and ongoing, so the risk it's
addressing is tangible and we have some reasonably solid information about
how it works.  So while it may not be the most serious problem, it's one
of the problems we understand the best, and therefore are in a good
position to do something about.

> I would be a lot more worried about what reportbug does when a package
> suggests libdvdcss2 - in some jurisdictions this might just be enough
> when the government is looking for a reason to raid your home.

I'm a great believer in ubiquitous encryption, even if it seems silly,
just on the grounds of "why not?".  We should encrypt reportbug traffic
too, if we can.  Yes, a lot of the details get exposed at the other end
anyway (although not necessarily), but it's usually fairly trivial to
encrypt links, and if it is, there's basically no reason not to.

-- 
Russ Allbery (r...@debian.org)   

Re: client-side signature checking of Debian archives (Re: When should we https our mirrors?)

[Paul Wise]

On Tue, Oct 25, 2016 at 7:33 AM, Russ Allbery wrote:

> Tor is easier for us as a project, since we don't really have to do
> anything (assuming we just rely on existing exit nodes).

Debian has Tor onion service frontends to various Debian services,
including several Debian machines with archive mirrors, this is
implemented in an automated way using Puppet and onionbalance. So we
do not rely on Tor exit nodes, just relays and the onion service
system.

https://onion.debian.org/
https://anonscm.debian.org/cgit/mirror/dsa-puppet.git/tree/modules/onion

> SSL is much harder for us as a project

For most debian.org services run by DSA, enabling SSL on a service is
one git commit away, thanks to Lets Encrypt.

Some things like snapshot are harder due to software or other issues.
For snapshot, varnish is the frontend and it doesn't support SSL.

All the debian.org mirrors except ftp.d.o are not actually run by DSA
and DSA occasionally need to change which domain points to which
mirror, so SSL for them is much more complicated.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

"PIE by default" transition is underway -- wiki needs updating

[Steve M. Robbins]

Hi,

I haven't been paying close attention to the "PIE by default" [1] discussions, 
so I may have missed the memo, but: it seems the transition is underway?  

I've seen two bugs already claiming "static library foo must be compiled with 
-fPIC" -- because some reverse dependency now fails to build.  But I think 
this advice is misplaced.  The Ubuntu page [2] says that all you need to do is 
rebuild the library foo with the PIE-enabled compiler, then rebuild the 
depending code:

Relocation Linking Failure

A dynamically linked program that pulls in a static library that was 
not 
built with -fPIC. These give an error like: 

relocation R_X86_64_32 against '[SYMBOL]' can not be used when 
making a 
shared object; recompile with -fPIC

To address these types of issues, the package providing the static 
object 
needs to be rebuilt (usually just a no-change rebuild against the 
pie-by-
default compiler) before rebuilding the failed package. 


So it seems to me that this should be emphasized on the wiki [1].  Secondly, 
it seems that the proposal to change policy to encourage -fPIC on static 
libraries [3] is misplaced and should be withdrawn.Are both these 
statements accurate?

Thanks,
-Steve

[1] https://wiki.debian.org/Hardening/PIEByDefaultTransition
[2] https://wiki.ubuntu.com/SecurityTeam/PIE
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837478


signature.asc
Description: This is a digitally signed message part.

Re: client-side signature checking of Debian archives (Re: When should we https our mirrors?)

[Russ Allbery]

Paul Wise  writes:

> Debian has Tor onion service frontends to various Debian services,
> including several Debian machines with archive mirrors, this is
> implemented in an automated way using Puppet and onionbalance. So we do
> not rely on Tor exit nodes, just relays and the onion service system.

> https://onion.debian.org/
> https://anonscm.debian.org/cgit/mirror/dsa-puppet.git/tree/modules/onion

Oh, interesting, thank you.  I hadn't realized that.  That definitely
makes Tor more attractive.

-- 
Russ Allbery (r...@debian.org)   

Bug#841996: ITP: node-repeating -- Repeat a string fast

[Sruthi Chandran]

Package: wnpp
Severity: wishlist
Owner: Sruthi Chandran 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: node-repeating
  Version : 3.0.0
  Upstream Author : Sindre Sorhus 
(sindresorhus.com)
* URL : https://github.com/sindresorhus/repeating#readme
* License : Expat
  Programming Lang: JavaScript
  Description : Repeat a string - fast

Bug#841998: ITP: node-strip-indent -- Strip leading whitespace from each line in a string

[Sruthi Chandran]

Package: wnpp
Severity: wishlist
Owner: Sruthi Chandran 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: node-strip-indent
  Version : 2.0.0
  Upstream Author : Sindre Sorhus 
(sindresorhus.com)
* URL : https://github.com/sindresorhus/strip-indent#readme
* License : Expat
  Programming Lang: JavaScript
  Description : Strip leading whitespace from each line in a string

Bug#841999: ITP: node-trim-newlines -- Trim newlines from the start and/or end of a string

[Sruthi Chandran]

Package: wnpp
Severity: wishlist
Owner: Sruthi Chandran 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: node-trim-newlines
  Version : 1.0.0
  Upstream Author : Sindre Sorhus 
(sindresorhus.com)
* URL : https://github.com/sindresorhus/trim-newlines
* License : Expat
  Programming Lang: JavaScript
  Description : Trim newlines from the start and/or end of a string