Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

[Robert Edmonds]

The entire DNS root zone is only 1 MB compressed and is updated about
once a day. It would be even better for privacy if the whole root zone
were distributed via HTTPS, as the initiator would not reveal to the
server any information about what TLD is being looked up.

There are currently ~1500 TLDs in the root zone. Dividing 1 MB by the
number of TLDs, this is ~700 bytes per TLD, which is roughly the amount
of bandwidth required by a query/response pair of UDP DNS packets to
obtain the delegation for a TLD.

The size of the DNS root zone could also be reduced if it were signed by
an ECC algorithm rather than RSA.

If the ZONEMD resource record (draft-ietf-dnsop-dns-zone-digest) were
standardized and deployed in the root zone, it would allow for
cryptographic verification of the entire contents of the root zone
regardless of the source. So it would not even be necessary to obtain
the root zone from the "official" root name server infrastructure.

That moves the problem down a level to the TLDs, where it is
impracticable to distribute copies of all TLD zone files. So a better
question to ask would be whether any of the DNS TLD servers plan to
implement any of the DNS transport privacy options. That moves the
problem down another level, etc.

The benefit of encrypting the resolver to authoritative side of the DNS
protocol is that it makes it possible to deploy "non stub" caching DNS
resolvers to individual hosts without exposing the plaintext lookup
traffic to either network observers or a centralized resolver operator
such as an ISP or cloud provider.

Ondřej Surý wrote:
> DNSCurve - probably never
> 
> DoT - the current profiles are stub to resolver, when they are profiles for 
> resolver to authoritative and a solid support in the software, the RSSAC will 
> surely talk about this. The deployment will have impact (switching all 
> traffics to TCP? Yay?)
> 
> DoH - I am not sure what would be the benefit for resolver to authoritative, 
> but same as with DoT.
> 
> DNSoQUIC - not yet there, but it might be better option for resolver to 
> authoritative...
> 
> Ondřej
> --
> Ondřej Surý 
> 
> > On 9 Sep 2019, at 03:17, Paul Wise  wrote:
> > 
> > On Mon, Sep 9, 2019 at 2:31 AM Ondřej Surý wrote:
> > 
> >> Mozilla plans to enable DoH to CloudFlare by default to US based users
> > 
> > Does anyone know if there is any plan for the DNS root servers to
> > enable any of the DNS privacy options? AFAIK the available options are
> > DNSCurve, DoT or DoH.
> > 
> > -- 
> > bye,
> > pabs
> > 
> > https://wiki.debian.org/PaulWise
> > 
> 

-- 
Robert Edmonds
edmo...@debian.org

Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

[Ondřej Surý]

On the privacy topic...

Slides: https://irtf.org/anrw/2019/slides-anrw19-final44.pdf
Paper: https://dl.acm.org/authorize.cfm?key=N687437

And you can get to the video recording from the ANRW 2019 pages: 
https://irtf.org/anrw/2019/program.html

We can discuss (and it has been discussed) ad nauseam, but the point is that 
nobody (certainly I am not) is asking for crippling DoH, but I just strongly 
believe it’s in the line with other Debian work that we should not send data to 
3rd party DNS service without explicit user consent.

Otherwise it doesn’t make any sense to remove external links to logos and 
JavaScript from the documentation and then send everything to one single 
US-based provider.

Ondrej
--
Ondřej Surý 

> On 8 Sep 2019, at 23:29, Marco d'Itri  wrote:
> 
> On Sep 08, Ondřej Surý  wrote:
> 
>> I would rather see an explicit statement. I would be very surprised 
>> with Debian’s usual stance regarding the users’ privacy that we would 
>> not consider this as a privacy violation, but again I am not Firefox 
>> maintainer in Debian and I would rather hear from them than speculate 
>> on my own.
> I think that this is a privacy enhancement, since it prevents some major 
> ISPs from spying on users DNS queries. When it will be enabled in other 
> countries it will prevent government-mandated (or "encouraged")
> censorship.
> It would be a terrible signal if Debian decided to disable an 
> anti-censoship feature provided by an upstream vendor.
> 
> -- 
> ciao,
> Marco

Re: Git Packaging Round 2: When to Salsa mirror

[Geert Stappers]

On Sun, Sep 08, 2019 at 10:05:17PM -0700, Russ Allbery wrote:
> Sean Whitton  writes:
> > On Sun 08 Sep 2019 at 05:35PM -04, Sam Hartman wrote:
> 
> >> You are encouraged to mirror your repository to Salsa so that people can
> >> find more of the Debian packaging in one place.
> 
> > Hmm, if the Vcs-* are set correctly, what's the value of mirroring to
> > salsa?  (I don't object in the least; just wondering about the value.)
> 
> Higher chance that the repository won't go away.

Where is Alioth? As retoric question.

What about Vcs-Mirror-*  for actual telling where a mirror is.
In case of `git` is "mirror" a "clone"


Groeten
Geert Stappers
-- 
Leven en laten leven


signature.asc
Description: PGP signature

Re: Git Packaging Round 2: When to Salsa

[Russ Allbery]

Sean Whitton  writes:
> On Sun 08 Sep 2019 at 05:35PM -04, Sam Hartman wrote:

>> You are encouraged to mirror your repository to Salsa so that people can
>> find more of the Debian packaging in one place.

> Hmm, if the Vcs-* are set correctly, what's the value of mirroring to
> salsa?  (I don't object in the least; just wondering about the value.)

Higher chance that the repository won't go away.  For instance, the
primary home of all of my packaging repositories is on my own Git server
and will continue to be because I like to have my own personal control
over such things, but it's in the project's best interest for me to mirror
them to Salsa so that if I suddenly make millions of dollars and decide I
just want to read books and stop running online services, the repositories
don't become inaccessible.

(Of course, I upload all of my stuff with dgit, so even in that case not
everything would be lost, but Salsa would preserve unreleased work,
branches that weren't uploaded with dgit, and so forth.)

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

Re: Git Packaging Round 2: When to Salsa

[Sean Whitton]

Hello,

On Sun 08 Sep 2019 at 05:35PM -04, Sam Hartman wrote:

> You are encouraged to mirror your repository to Salsa so that people can
> find more of the Debian packaging in one place.

Hmm, if the Vcs-* are set correctly, what's the value of mirroring to
salsa?  (I don't object in the least; just wondering about the value.)

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

[Ondřej Surý]

DNSCurve - probably never

DoT - the current profiles are stub to resolver, when they are profiles for 
resolver to authoritative and a solid support in the software, the RSSAC will 
surely talk about this. The deployment will have impact (switching all traffics 
to TCP? Yay?)

DoH - I am not sure what would be the benefit for resolver to authoritative, 
but same as with DoT.

DNSoQUIC - not yet there, but it might be better option for resolver to 
authoritative...

Ondřej
--
Ondřej Surý 

> On 9 Sep 2019, at 03:17, Paul Wise  wrote:
> 
> On Mon, Sep 9, 2019 at 2:31 AM Ondřej Surý wrote:
> 
>> Mozilla plans to enable DoH to CloudFlare by default to US based users
> 
> Does anyone know if there is any plan for the DNS root servers to
> enable any of the DNS privacy options? AFAIK the available options are
> DNSCurve, DoT or DoH.
> 
> -- 
> bye,
> pabs
> 
> https://wiki.debian.org/PaulWise
> 

Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

[Paul Wise]

On Mon, Sep 9, 2019 at 2:31 AM Ondřej Surý wrote:

> Mozilla plans to enable DoH to CloudFlare by default to US based users

Does anyone know if there is any plan for the DNS root servers to
enable any of the DNS privacy options? AFAIK the available options are
DNSCurve, DoT or DoH.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

[Adam Borowski]

On Sun, Sep 08, 2019 at 11:17:13PM +0200, Marco d'Itri wrote:
> On Sep 08, Ondřej Surý  wrote:
> 
> > I would rather see an explicit statement. I would be very surprised 
> > with Debian’s usual stance regarding the users’ privacy that we would 
> > not consider this as a privacy violation, but again I am not Firefox 
> > maintainer in Debian and I would rather hear from them than speculate 
> > on my own.
> I think that this is a privacy enhancement, since it prevents some major 
> ISPs from spying on users DNS queries. When it will be enabled in other 
> countries it will prevent government-mandated (or "encouraged")
> censorship.

DoH doesn't stop ISP-based spying nor censorship.  On the other hand, it
allows a new third party (Cloudflare in Mozilla's default) to do both such
spying and censorship -- something it couldn't do before.

Let's compare; by "ISP" I mean every hop on the network path.

With local DNS:
* the target server knows about you (duh!)
* the ISP can read the destination of every connection
  [reading the DNS packets, reading the IP header, reading SNI header]
* the ISP can block such connections
  [blocking DNS packets, blocking actual connection]
* DNSSEC forbids falsifying DNS

With DoH:
* the target server knows about you (duh!)
* the ISP can read the destination of every connection
  [reading the IP header, reading SNI header]
* the ISP can block such connections
  [blocking actual connection]
* Cloudflare can read the destination of every connection
  [they serve the DNS...]
* Cloudflare can falsify DNS¹
* Cloudflare can block connections
  [blocking or falsifying DNS response]

So currently DoH is strictly worse.

In the future, once ESNI is implemented and deployed, the ISP will lose the
possibility of distinguishing sites served from the same IP, but that helps
with some random blogs while most sensitive sites can't trust a shared
hoster.  Thus, ESNI hardly helps.

> It would be a terrible signal if Debian decided to disable an 
> anti-censoship feature provided by an upstream vendor.

If that feature worked, that'd would indeed be terrible.  But in the current
proposal, it's a privacy violation with no clear upside.  I'd thus recommend
to _not_ enable DoH in our packages.


Meow!

[1]. It would be possible to, instead of sending just the answer, to pass
the entire chain of DNSSEC signatures over the DoH link.  This has been
suggested in RFC8484, but doesn't seem to be implemented by Firefox.
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Snowflakes?  Socks drawer!
⢿⡄⠘⠷⠚⠋⠀
⠈⠳⣄

Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

[Jeremy Stanley]

On 2019-09-08 23:17:13 +0200 (+0200), Marco d'Itri wrote:
[...]
> I think that this is a privacy enhancement, since it prevents some
> major ISPs from spying on users DNS queries.
[...]

While at the same time legitimizing Cloudflare spying on users' DNS
queries, right? How is one necessarily better than the other? My ISP
can spy on far fewer users than Cloudflare can, so on balance this
seems like a net loss for privacy.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature

Git Packaging Round 2: When to Salsa

[Sam Hartman]

So, this is much harder than the dh discussion.
Here, we're not trying to come to a consensus on policy changes.
And here, the level of agreement is not as high.

I'd like to start by thanking the Salsa admins for running a great
service and for answering some naive questions I had while putting this
mail together.

First, I guess I should see if we're in the same place on what we're
trying to accomplish.

Based on what I've seen, I think we can come up with recommendations
that are entirely optional.
One purpose these can serve is to guide people who are starting a new
package and simply want to follow something they know a bunch of other
people are doing.

In some cases we can make conditional recommendations about best
practice.  Fore example, in round one we seem to have agreed that
leaving merge requests enabled while entirely ignoring them with no one
set to receive notifications is a definite worst practice.

Judging consensus on optional recommendations is harder than judging
consensus in the dh discussion.  For example "Hey, I do not want to do
that," may not even be an argument against a recommendation.  Similarly,
"There are circumstances where that would be wrong," may be an argument
for documenting the circumstances or may even be an argument for no
change.

I can really use your help here.  If you're providing feedback please
make it clear whether you're arguing to refine/constrain the
recommendation, just providing context, or arguing that I'm misreading
what we as a community want to do.  And as always, it's more helpful if
you explain why.

Deferred for Round 3


In this message I'm trying to focus on when we should use
salsa.debian.org and where we should put stuff on that server.

I'm hoping to cover git branch format, upstream tarballs, pristine-tar,
and upstream integrity in round 3.

General Recommendation
==

This recommendation is intended for people who are simply looking for an
approach that will work well with approaches others are using.  If you
are packaging something in a large team, follow their existing
practices.  If you are setting up a new team, see the recommendation for
teams.  If you have your own ideas about what you'd like to do and
choose to disregard this recommendation, that is also fine.  If you
do not already know the answer you want, this recommendation is for you.

If you are a Debian Developer packaging a package for inclusion in
Debian, you should store your packaging information in one repository
per package on salsa.debian.org in the debian group.  That is you should
create a repository under https://salsa.debian.org/debian .

You should make sure that at least one person sets their notification
level to 'watch' rather than global.  This way you will receive
notifications of merge requests and changes.

Hopefully you will choose to monitor merge requests for your
repository.  If not, turn off merge requests.

If you are not a Debian Developer, you cannot directly create a
repository in the debian group.  If you're willing to wait for a Debian
Developer to create a repository for you and grant you access, that may
make things simpler longer-term.  If that wait would be long enough to
frustrate you or demotivate you, you should
[do what?  Create a repo in their personal namespace on salsa?]

By creating a repository in the debian group, you grant access to all
developers.  That way people performing NMUs can directly commit their
changes.  It will also make it easier if you later orphan the package to
preserve version control history.

The Salsa CA pipeline is recommended.

Notes and Limitations
-

The debian group is great for relatively unrelated packages.  It may not
be appropriate for a large number of related packages (especially when
maintained by a team) for these reasons:

* It is hard to examine the group of related packages without also
  seeing other unrelated packages

* You cannot subscribe to watch a group of related packages with one
  click

* Access to people who are not Debian Developers needs to be granted on
  a per-repository basis in the debian group

Some teams with a large number of packages have adopted a
monolithic format where a single repository contains information for
many packages.  It is not the intent of this recommendation to judge
that approach either positively or negatively; this recommendation is
targeted at a very different audience.

This recommendation is not appropriate in cases when Debian Developers
should not have push access to the repository.  For example if you are
mirroring the repository from another service and do not want changes
pushed to this replica, using the debian group is inappropriate.

Discussion Comments
---

This is my notes for the debian-devel discussion.  I'm not sure how much
of any of the text here will survive into something that lasts, but the
"discussion comments" subsections are explicitly intended only for thi

Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

[Marco d'Itri]

On Sep 08, Ondřej Surý  wrote:

> I would rather see an explicit statement. I would be very surprised 
> with Debian’s usual stance regarding the users’ privacy that we would 
> not consider this as a privacy violation, but again I am not Firefox 
> maintainer in Debian and I would rather hear from them than speculate 
> on my own.
I think that this is a privacy enhancement, since it prevents some major 
ISPs from spying on users DNS queries. When it will be enabled in other 
countries it will prevent government-mandated (or "encouraged")
censorship.
It would be a terrible signal if Debian decided to disable an 
anti-censoship feature provided by an upstream vendor.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#939796: ITP: lxqt-kcm-integration -- Integration package for several KDE control modules into LXQt

[Alf Gaida]

Package: wnpp
Severity: wishlist
Owner: Alf Gaida 

* Package name: lxqt-kcm-integration
  Version : 0.0.1
  Upstream Author : Alf Gaida 
* URL : https://github.com/lxqt/lxqt-kcm-integration
* License : (LGPL2+)
  Programming Lang: (desktop files)
  Description : Integration package for several KDE control modules into 
LXQt

Right now the set of controls include:
* KCM KWin settings
* KCM Appearance
* KCM Bluetooth
* KCM Systeminfo

The package will ease the pain when $user descide to use kwin with LXQt.
The LXQt packaging team will maintain the package.

Mozilla Firefox DoH to CloudFlare by default (for US users)?

[Ondřej Surý]

Hi,

I haven’t found any discussion on the topic (although I haven’t searched very 
hard and only looked for DoH and DNS keywords in the BTS), but since Mozilla 
plans to enable DoH to CloudFlare by default to US based users: 
https://blog.mozilla.org/futurereleases/2019/09/06/whats-next-in-making-dns-over-https-the-default/
 I would rather see an explicit statement. I would be very surprised with 
Debian’s usual stance regarding the users’ privacy that we would not consider 
this as a privacy violation, but again I am not Firefox maintainer in Debian 
and I would rather hear from them than speculate on my own.

Thanks,
Ondřej
--
Ondřej Surý 

Bug#939772: ITP: node-es-abstract -- ECMAScript spec abstract operations

[Bastien Roucariès]

Package: wnpp
Severity: wishlist
Owner: Bastien Roucariès 

  Package name: node-es-abstract
  Version : 1.14.2
  Upstream Author : Jordan Harband (ljharb)
  URL : https://github.com/ljharb/es-abstract
  License : expat
  Programming Lang: javascript
  Description : ECMAScript spec abstract operations.

In order to facilitate their use in multiple parts of this ECMAScript 
specification
(javascript) some algorithms, called abstract operations, are named and written 
in
parameterized functional form so that they may be referenced by name
from within other algorithms. 
.
Abstract operations are typically referenced using a functional application 
style such as OperationName(arg1, arg2). 
Some abstract operations are treated as polymorphically dispatched methods of 
class-like specification abstractions.
.
This module implement this abstract operation as functions.

This module is useful for mocha a javascript tester useful for debci

javascript team

Bug#939771: ITP: node-es-abstract -- ECMAScript spec abstract operations.

[Bastien Roucariès]

Package: wnpp
Severity: wishlist
Owner: Bastien Roucariès 

  Package name: node-es-abstract
  Version : 1.14.2
  Upstream Author : Jordan Harband (ljharb)
  URL : https://github.com/ljharb/es-abstract
  License : expat
  Programming Lang: javascript
  Description : ECMAScript spec abstract operations.

In order to facilitate their use in multiple parts of this ECMAScript 
specification
(javascript) some algorithms, called abstract operations, are named and written 
in
parameterized functional form so that they may be referenced by name
from within other algorithms. 
.
Abstract operations are typically referenced using a functional application 
style such as OperationName(arg1, arg2). 
Some abstract operations are treated as polymorphically dispatched methods of 
class-like specification abstractions.
.
This module implement this abstract operation as functions.

This module is useful for mocha a javascript tester useful for debci

javascript team

Bug#939759: ITP: libnet-acme2-perl -- Client logic for the ACME (Let's Encrypt) protocol

[Salvatore Bonaccorso]

Package: wnpp
Owner: Salvatore Bonaccorso 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org

* Package name: libnet-acme2-perl
  Version : 0.32
  Upstream Author : Felipe Gasper
* URL : https://metacpan.org/release/Net-ACME2
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Client logic for the ACME (Let's Encrypt) protocol

Net::ACME2 implements client logic for the ACME (Automated Certificate
Management Environment) protocol, as standardized in RFC
8555|https://www.rfc-editor.org/rfc/rfc8555.txt and popularized by Let's
Encrypt|http://letsencrypt.org.

The package will be maintained under the umbrella of the Debian Perl Group.

-- 
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.