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

[Thomas Goirand]

On 9/10/19 7:46 PM, Marco d'Itri wrote:
> You obviously consider Mozilla's choices of trusted resolvers (currently 
> Cloudflare, hopefully others too in the future) a bigger privacy risk 
> for generic users (the one who use the browser defaults) than their ISP, 
> I disagree.

You shouldn't insist on always writing "their ISP", as if it was the
only choice. It isn't. One can setup his own recursive DNS locally, for
example. I've done this for years, as I didn't trust my ISP (first, in
China, now I don't trust here in Europe either).

Thomas

Re: Git Packaging Round 2: SHOULD Not or MUSt NOT Github

[Enrico Zini]

On Thu, Sep 12, 2019 at 03:51:57PM +0100, Ian Jackson wrote:

> Well, thanks for the rebuke.  I hope I have clarified my thinking and
> please do the same again in future.  (Or, indeed, right now, if you
> think this message is still frightening...)

I wish you could learn to *listen* first, then maybe argue. You still
proceeded to argue at me without really asking any question about where
I was coming from.

Sam showed you how the situation in Debian seems to be different from
what you understood, and your response was not to acknowledge, try to
understand, and map the current status quo, but to consider of a GR to
force the status quo to fit to your expectations.

This cannot be the discussion culture of a group where I can be
comfortable working with others.


Enrico

-- 
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini 


signature.asc
Description: PGP signature

Re: Git Packaging Round 2: SHOULD Not or MUSt NOT Github

[Bastian Blank]

On Thu, Sep 12, 2019 at 06:34:42PM +0200, Alf Gaida wrote:
> Regarding the workflow and participation - it might be a problem that
> one need an account for github or other non-free services - it's easy:

You also need accounts for _free_ services, so what do you want to say?

Bastian

-- 
Lots of people drink from the wrong bottle sometimes.
-- Edith Keeler, "The City on the Edge of Forever",
   stardate unknown

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

[Marco d'Itri]

On Sep 13, Thomas Goirand  wrote:

> You shouldn't insist on always writing "their ISP", as if it was the
> only choice. It isn't. One can setup his own recursive DNS locally, for
> example. I've done this for years, as I didn't trust my ISP (first, in
Sure, me too: but it does not matter, because if somebody knows how to 
setup a local resolver then they surely can change a browser setting as 
well.
We are talking about preventing large scale censorship (I do not think 
that this is really about privacy) for *general users*: obviously *we* 
already know about countless workarounds.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

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

[Marco d'Itri]

On Sep 13, Jeremy Stanley  wrote:

> Note that by way of counterargument, Google and its services have
> been blocked in mainland China by the Great Firewall for nearly a
> decade now, so I question whether there is really such a thing as
> "too big to block."
This is a false dichotomy: not all nation states are willing to go to 
the extreme lengths as China.
Also, this is a cat and mouse game and DoH is probably just the next 
step :encrypted SNI will probably be needed as well later.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

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

[Ondřej Surý]

> On 13 Sep 2019, at 12:25, Marco d'Itri  wrote:
> 
> We are talking about preventing large scale censorship (I do not think 
> that this is really about privacy) for *general users*: obviously *we* 
> already know about countless workarounds.

That’s a false statement. Right now, we are talking about sending _all_ your 
queries from
just **one** application - Mozilla Firefox.  And what’s worse - if we are 
talking about protecting
the users, it could lead to a false sense of protection - any other application 
in the system
will send the DNS queries through stub resolver (e.g. most probably to whatever 
the system
gets from the DHCP).

Again, please note, I am not advocating against DoH or DoT, I just think we 
need to do
a better job to protect our users than blindly following Mozilla’s lead by 
enabling it by default
without explicit user consent.

BTW there’s a new initiative - Encrypted DNS and if you look closely, ISC is on 
the list of
participants from the very beginning.  There’s no doubt that we need to encrypt 
DNS, but
in a way that won’t lead to every app sending it’s DNS queries to a different 
resolver.

Ondrej
--
Ondřej Surý
ond...@sury.org

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

[Simon Richter]

Hi,

On Fri, Sep 13, 2019 at 12:28:23PM +0200, Marco d'Itri wrote:

> > Note that by way of counterargument, Google and its services have
> > been blocked in mainland China by the Great Firewall for nearly a
> > decade now, so I question whether there is really such a thing as
> > "too big to block."

> This is a false dichotomy: not all nation states are willing to go to 
> the extreme lengths as China.

Also, China cannot block Github, because they have no equivalent, and even
if they did, it wouldn't have the same content. Google is too easily
replicated, because they have no immediate contributors.

I expect that China will set up a proxy service with clones of all relevant
Github repositories soon to keep read-only access to free software around
but inhibit organizing through shared documents.

CloudFlare has too many services behind them that are important for the
economy and not replicable, so they are in a better position than Github
here.

> Also, this is a cat and mouse game and DoH is probably just the next 
> step :encrypted SNI will probably be needed as well later.

Mandatory Encrypted SNI with no fallback option -- everything else can be
circumvented easily.

This is a game that we should not play, really. It raises the cost of
running a service on the Internet so only big players can afford to do so.

We are throwing some ice cubes into the boiling pot so there are local
zones that are warming up slow enough that the frogs there do not notice.
This is a losing strategy.

   Simon

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

[Marco d'Itri]

On Sep 13, Ondřej Surý  wrote:

> > We are talking about preventing large scale censorship (I do not think 
> > that this is really about privacy) for *general users*: obviously *we* 
> > already know about countless workarounds.
> That’s a false statement. Right now, we are talking about sending _all_ your 
> queries from
> just **one** application - Mozilla Firefox.  And what’s worse - if we are 
> talking about protecting
> the users, it could lead to a false sense of protection - any other 
> application in the system
> will send the DNS queries through stub resolver (e.g. most probably to 
> whatever the system
> gets from the DHCP).
I have never argued for or against "protecting users": the problem 
I care about is DNS-based censorship of web sites and DoH from the 
browser to a third party resolver solves this, at least for the time 
being.

> BTW there’s a new initiative - Encrypted DNS and if you look closely, ISC is 
> on the list of
I have seen it: it is an interesting list of companies selling 
DNS-related products or services, USA ISPs who are highly suspect in 
their sudden interest in their customers' privacy and of UK ISPs that 
I assume are subject to regulatory pressure.

> participants from the very beginning.  There’s no doubt that we need to 
> encrypt DNS, but
> in a way that won’t lead to every app sending it’s DNS queries to a different 
> resolver.
This would be nice: maybe a few of these large companies would like to 
fund adding DoH support to systemd-resolved?

-- 
ciao,
Marco


signature.asc
Description: PGP signature

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

[Holger Levsen]

On Thu, Sep 12, 2019 at 11:02:22PM +0200, Wouter Verhelst wrote:
> Except DoH is *not* an anti-censorship feature. It is a feature that
> provides a net reduction in privacy.

agreed.

> CloudFlare says that it won't read your DNS requests -- scout's honour!
> -- but even if that's true and we can believe it, there's no reason to
> assume it will continue to do so forever, past any potential future
> acquisitions or CEO changes.

exactly.

> Mozilla really missed the ball on this one. OpenBSD already made the
> necessary changes to Firefox. I think we should, too.

agreed.

so, iceweasel again? :)


-- 
cheers,
Holger

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


signature.asc
Description: PGP signature

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

[Evilham]

On dv., set. 13 2019, Simon Richter wrote:


Hi,

On Fri, Sep 13, 2019 at 12:28:23PM +0200, Marco d'Itri wrote:

> Note that by way of counterargument, Google and its services 
> have
> been blocked in mainland China by the Great Firewall for 
> nearly a
> decade now, so I question whether there is really such a 
> thing as

> "too big to block."


This is a false dichotomy: not all nation states are willing to 
go to

the extreme lengths as China.


Also, China cannot block Github, because they have no 
equivalent, and even
if they did, it wouldn't have the same content. Google is too 
easily

replicated, because they have no immediate contributors.

I expect that China will set up a proxy service with clones of 
all relevant
Github repositories soon to keep read-only access to free 
software around

but inhibit organizing through shared documents.

CloudFlare has too many services behind them that are important 
for the
economy and not replicable, so they are in a better position 
than Github

here.

Also, this is a cat and mouse game and DoH is probably just the 
next

step :encrypted SNI will probably be needed as well later.


Mandatory Encrypted SNI with no fallback option -- everything 
else can be

circumvented easily.

This is a game that we should not play, really. It raises the 
cost of
running a service on the Internet so only big players can afford 
to do so.


We are throwing some ice cubes into the boiling pot so there are 
local
zones that are warming up slow enough that the frogs there do 
not notice.

This is a losing strategy.

   Simon



There's also this:
 https://use-application-dns.net/
 https://tools.ietf.org/html/draft-grover-add-policy-detection-00

The way I read it, it means that "soon" DoH would be enabled by 
default for "everyone" unless it can be trivially disabled by the 
network operator.


Quite confusing, at least for me it'd look as having all the 
issues of centralising DNS (a couple kill-switches for de-facto 
global censorship) and then undoing all the benefits of using 
encrypted DNS in the first place.

--
Evilham

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

[Sam Hartman]

> "Holger" == Holger Levsen  writes:

>> Mozilla really missed the ball on this one. OpenBSD already made
>> the necessary changes to Firefox. I think we should, too.

Holger> agreed.

OK, so, it seems like the way we do things, that's going to be the
firefox maintainer's decision.

I think right now this discussion is drifting away from being
productive.  There's not a clear consensus and people are starting to
repeat each other.
It could be useful if any of a number of things are happen:

* The firefox maintainers pop up and say it is useful to them.  For
  example if they are trying to get additional input to make a
  decision.  (My assumption is that the firefox maintainers have not
  been particularly active in this discussion.  If so, my entire basis
  for this message may be wrong.  In a different worldh I would go check
  and see who all the active firefox maintainers were and see if they
  have been active)

* Someone volunteers to write up the arguments made here as part of a
  bug requesting either no change or some change.  Obviously such a bug
  could point to this discussion and better yet summarize the arguments
  made.

--Sam

Re: Git Packaging Round 2: SHOULD Not or MUSt NOT Github

[Alf Gaida]

On 9/13/19 10:18 AM, Bastian Blank wrote:
> On Thu, Sep 12, 2019 at 06:34:42PM +0200, Alf Gaida wrote:
>> Regarding the workflow and participation - it might be a problem that
>> one need an account for github or other non-free services - it's easy:
> You also need accounts for _free_ services, so what do you want to say?

Is it really so hard to understand? Github, Gitlab and other service are
just tools. I don't care if they are free or non-free. No account, no
participation. And if you had read the whole post - imho the best
outcome woul be: No hosting of Debian packaging outside  Debian
infrastructure. Second thing i would prefer: Packaging has to use a VCS
supported in the debian project. If it boils down to:  We  support only
git in our infrastructure - fine.

Cheers Alf

>
> Bastian
>

Re: Git Packaging Round 2: When to Salsa

[gregor herrmann]

On Thu, 12 Sep 2019 08:14:13 -0400, Sam Hartman wrote:

> I did do a bit of looking at data.
> In my unstable sources.list, there are 17863 source packages that
> include salsa.debian.org in the vcs-git.  Of those, 2192 are in the
> debian group.
> That's the largestsingle group; perl-team (next) comes in at 1417.

That's obviously an artifact of our poor Vcs-* information handling
(in source packages); in reality, of course all of the 3600+
perl-team packages are maintained on salsa.
 

Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   


signature.asc
Description: Digital Signature

Re: Git Packaging Round 2: When to Salsa

[Xavier]

Le Vendredi, Septembre 13, 2019 15:00 CEST, gregor herrmann  
a écrit:
> On Thu, 12 Sep 2019 08:14:13 -0400, Sam Hartman wrote:
>
> > I did do a bit of looking at data.
> > In my unstable sources.list, there are 17863 source packages that
> > include salsa.debian.org in the vcs-git.  Of those, 2192 are in the
> > debian group.
> > That's the largestsingle group; perl-team (next) comes in at 1417.
>
> That's obviously an artifact of our poor Vcs-* information handling
> (in source packages); in reality, of course all of the 3600+
> perl-team packages are maintained on salsa.

Hi,

same for JS-Team packages (~2600)

Regards,
Xavier

Re: Git Packaging Round 2: SHOULD Not or MUSt NOT Github

[Simon Richter]

Hi,

On Fri, Sep 13, 2019 at 02:51:47PM +0200, Alf Gaida wrote:

> Is it really so hard to understand? Github, Gitlab and other service are
> just tools. I don't care if they are free or non-free.

For Debian, free software is kind of important.

   Simon

Re: Git Packaging Round 2: SHOULD Not or MUSt NOT Github

[Alf Gaida]

On 13.09.19 15:10, Simon Richter wrote:
> Hi,
>
> On Fri, Sep 13, 2019 at 02:51:47PM +0200, Alf Gaida wrote:
>
>> Is it really so hard to understand? Github, Gitlab and other service are
>> just tools. I don't care if they are free or non-free.
> For Debian, free software is kind of important.
>
>Simon

Simon - if you cite me, you should cite the relevant part. Really, the
text wasn't that long:

> Is it really so hard to understand? Github, Gitlab and other service are
> just tools. I don't care if they are free or non-free. No account, no
> participation. And if you had read the whole post - imho the best
> outcome woul be: No hosting of Debian packaging outside  Debian
> infrastructure. Second thing i would prefer: Packaging has to use a VCS
> supported in the debian project. If it boils down to:  We  support only
> git in our infrastructure - fine.

No hosting outside of debian means: One has to use Debian infrastructure
- and we only use services we consider free, don't we? So it's is not
relevant if other services are free or non-free. It wouldn't matter.


Cheers Alf

Re: Git Packaging Round 2: SHOULD Not or MUSt NOT Github

[Bastian Blank]

On Fri, Sep 13, 2019 at 02:51:47PM +0200, Alf Gaida wrote:
> On 9/13/19 10:18 AM, Bastian Blank wrote:
> > On Thu, Sep 12, 2019 at 06:34:42PM +0200, Alf Gaida wrote:
> >> Regarding the workflow and participation - it might be a problem that
> >> one need an account for github or other non-free services - it's easy:
> > You also need accounts for _free_ services, so what do you want to say?
> Is it really so hard to understand? Github, Gitlab and other service are
> just tools. I don't care if they are free or non-free. No account, no
> participation.

You imply that by using _free_ services, you need _no_ accounts.  This
statement is false.

Bastian

-- 
There is a multi-legged creature crawling on your shoulder.
-- Spock, "A Taste of Armageddon", stardate 3193.9

Re: Git Packaging Round 2: When to Salsa

[Bastian Blank]

Hi Sam

On Sun, Sep 08, 2019 at 05:35:10PM -0400, Sam Hartman wrote:
> The Salsa CA pipeline is recommended.

For this I need to use my veto as Salsa admin.  With the CI people we
have to work through too much problems first.

I don't have anything else to add for now.

Bastian

-- 
Totally illogical, there was no chance.
-- Spock, "The Galileo Seven", stardate 2822.3

DNF for Debian

[Mihai Moldovan]

Hi


I've packaged DNF for Debian and would like to find someone to take over these
packages and maintain them as part of the distribution.

I'm not a DD and while I believe the packages to be of reasonable if not high
quality, I already have enough on my plate and know that I will not be able to
properly maintain them, keep up with upstream releases etc.
Point in case: while I did the original packaging more than a year, I only
updated this set of packages recently when they actually broke with newer Fedora
releases (i.e., they were too old to create newer Fedora changeroots when used
by mock).



== What is DNF? ==

For a long time, Fedora/RHEL/CentOS (and derivatives) used YUM as their default
package manager. DNF is a feature-rich YUM fork intended to replace it
eventually, using libsolv as its dependency solver, entered Fedora in version 18
as an option and has been its default package manager since version 22. RHEL 8,
based on Fedora 28, also already uses DNF as its default package manager.



== Why does Debian need DNF? ==

Debian already has packages for yum and mock. Building RPM packages on a Debian
system is a supported use case already utilized by a (probably rather small
amount) of users. That alone is normally not enough reason to introduce new
packages, but newer Fedora versions use features like boolean (or rich)
dependencies[0] that are plainly not supported by yum. Building such chroots
will flat out fail. DNF is now a hard dependency for supporting newer Fedora and
RHEL versions.

Without DNF, Debian would at some point lose the ability to be used a build host
for RPM packages.

Debian does NOT need DNF as an additional native package manager, but that
should be pretty clear. No sane user would (and should) try to mix dpkg/apt and
rpm/{yum,dnf} packages on a Debian system.



== Prerequisites ==

Most packages within unstable/sid are new enough.

The rpm source package needs a few rather trivial backports for new RPM tags -
submitted as https://bugs.debian.org/940114

The libsolv source package needs patches fixing its CMake integration, making it
usable with the "rpmdb-in-homedir" patch that is applied to Debian's rpm package
and enabling the COMPS feature - submitted as https://bugs.debian.org/889509

Eventually, I'd like Debian to completely drop the "rpmdb-in-homedir" patch
since it's causing more trouble than solving issues - a lengthy description of
why that is can be found in https://debugs.debian.org/794495 . While that is not
the case, we will have to patch libsolv to support that non-standard RPM 
behavior.



== Package List ==

=== libcomps 0.1.11-1 ===

Libcomps is library for structure-like manipulation of content in
comps XML files. Supports reading/writing XML files and structure
modifications.

Needed by: dnf


=== librepo 1.10.5-1 ===

A library providing C and Python (libcURL-like) APIs to
download repository metadata.

Needed by: libdnf


=== modulemd1 1.8.15-1 ===

A C library for manipulating module metadata files.

Needed by: libdnf, dnf


=== libdnf 0.35.3-1 ===

A library providing simplified C and Python APIs to libsolv.

Needed by: dnf


=== dnf 4.2.9-1 ===

Package manager forked from Yum, using libsolv as a dependency resolver.

Needed by: as explained above, also dnf-plugins-core


=== dnf-plugins-core 4.0.9-1 ===

This package enhances DNF with builddep, config-manager, copr, debug,
debuginfo-install, download, needs-restarting, repoclosure, repograph,
repomanage, reposync, changelog and repodiff commands.

Additionally provides generate_completion_cache passive plugin.

Needed by: mocks operation (builddep for instance) (not a proper dependency yet)



== Repository ==

Source and binaries (for unstable/sid, amd64) can be found at
https://packages.x2go.org/debian-test/pool/main/

If you want to test that, use something like

deb http://packages.x2go.org/debian-test sid main
deb-src http://packages.x2go.org/debian-test sid main



== Personal Note ===

I've been using DNF for the past one-and-a-half years for building RPM packages
on a Debian stretch machine. The proposed packages contain a few patches needed
for stretch integration (and stretch also needs changes to
gobject-introspection, glib and util-linux for DNF to build and work correctly).
I didn't want to rip them out and they don't cause trouble on newer-than-stretch
systems since their effect is essentially deactivated there. They are, however,
marked with "stretch" in the description and dropping them should be very easy.

They seemed to be very usable and stable for my use case - building RPM packages
via mock.



Mihai



[0] Debian/dpkg/apt has already known one of these "boolean(/rich) dependencies"
for quite some time - OR dependencies. RPM adds further ones, like (A if B)
which pulls in package A if B is already installed on the user system while
installing the dependent package, (A if B else C), which is the but extended
with a ternary term and crazier ones like (A with B), which inst

Re: Git Packaging Round 2: SHOULD Not or MUSt NOT Github

[Russ Allbery]

Alf Gaida  writes:

> Is it really so hard to understand? Github, Gitlab and other service are
> just tools. I don't care if they are free or non-free. No account, no
> participation. And if you had read the whole post - imho the best
> outcome woul be: No hosting of Debian packaging outside  Debian
> infrastructure. Second thing i would prefer: Packaging has to use a VCS
> supported in the debian project. If it boils down to:  We  support only
> git in our infrastructure - fine.

There seems to be an obvious ordering issue here, namely that it's very
weird to insist on the first (which has been the topic of this thread)
before we insist on the second.

Right now, we don't require people use *any* special tool to maintain
their packages.  They can just apt-get source, make changes with a text
editor, and then build a source package and upload.  It's therefore very
weird, and kind of off-putting, to have people who start using Git be
suddenly subject to *more* constraints about how they do their work than
people who aren't using a VCS at all.

If we get to the point where everyone has to use Git, then it's logical
(if possibly still not what we want to do) to take a more opinionated
stance on where those Git repositories are replicated to.  (And of course
the nice thing about Git is that you can easily put repositories in
multiple places.)  But for as long as we're not willing to require people
use a VCS (which I think would be rather controversial), it doesn't make
sense to me to have strong opinions about where the Git repository is if
they use one.

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

Re: Git Packaging Round 2: When to Salsa

[Sam Hartman]

> "Bastian" == Bastian Blank  writes:

Bastian> Hi Sam
Bastian> On Sun, Sep 08, 2019 at 05:35:10PM -0400, Sam Hartman wrote:
>> The Salsa CA pipeline is recommended.

Bastian> For this I need to use my veto as Salsa admin.  With the CI
Bastian> people we have to work through too much problems first.

What I am hearing you say is that right now, as service admins, you
cannot support the CI pipeline being used that widely.  I confirm that's
absolutely a call you get to make as a service adminand that forms a
blocking objection to recommending that now.
I'll remove it from the next version.

Are there additional resources either the salsa admins or the salsa CI
team needs to move forward to a place where you'd both feel comfortable
recommending Salsa CI?


Beyond that though, I think the term "veto" here tends to shut down
discussion in a way that is not good for the project.

The people running the service absolutely do get to decide what work
they are willing to do.  Or to say that they would need additional
resources to do something.

But your message and a couple of messages from Alex have come across
like you're saying that service maintainers get to veto things the
project wants.
You don't.

The project gets to decide what it wants.  You as service maintainers
get to decide how much of that you're interested in doing.  You can say
things like "To do that we'd need these things."  You can ask for people
to help, equipment, etc.
Or you can say something like "Actually, that's just beyond what we're
interested in doing no matter what resources we had."  That's all fine.

But the discussion may not stop there.
Often it will.  Often people will understand your point or not care
enough and drop the issue.

But sometimes people will want to talk about whether there are different
ways of splitting responsibilities or create a new team or something
where they can get something they value while respecting what the
current service maintainers are willing to do.

I think it's fine for you to veto something today.  But I'd encourage
you to do that in a manner that does not shutdown discussion about the
future while still being firm about what part of that future you're
interested in bringing about.

Thanks again for letting us all know that the CI pipeline is not ready
for a global recommendation.

--Sam

Re: Git Packaging Round 2: When to Salsa

[Sean Whitton]

Hello,

On Thu 12 Sep 2019 at 09:35PM +02, Marc Haber wrote:

> How about documenting that branches prefixed with "wip" can be force
> pushed any time and people pulling from those branches should be
> expected to handle that?

This would be useful.

I would already assume any branch prefixed with 'wip' might be rebased
myself, but others might be surprised.

-- 
Sean Whitton


signature.asc
Description: PGP signature

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

[Roger Lynn]

On 09/09/19 14:40, Bjørn Mork wrote:

Ondřej Surý  writes:

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.


Exactly. I'd be worried if anything in Debian came preconfigured with
DNS servers of any kind.


It apparently already does, although they appear to be used only under 
certain circumstances. See https://bugs.debian.org/761658


Roger

Re: Git Packaging Round 2: SHOULD Not or MUSt NOT Github

[Alf Gaida]

On 13.09.19 17:55, Russ Allbery wrote:
> There seems to be an obvious ordering issue here, namely that it's very
> weird to insist on the first (which has been the topic of this thread)
> before we insist on the second.

I wouldn't see it as an ordering issue - my POV is that each of these
issues is independend. Maybe it is just wishful thinking - but it would
not really matter, in which direction these issues would be addressed.


If i should setup a priority list it would be:

1) all packaging sources must be hosted in debian infrastructure (no
matter in which way)

2) all packages should use a SCM (no matter what)

3) finally (maybe) consider git as the only supported SCM


Each of these three points is controversial - i know. But it would be a
nice goal.


Cheers Alf

Re: Git Packaging Round 2: SHOULD Not or MUSt NOT Github

[Thomas Goirand]

On 9/12/19 2:47 PM, Sam Hartman wrote:
> 1) there are significant problems we'd run into if we forbid non-free tools in
> Debian work

Sorry, WHAAAT ? That's shocking to read this from the DPL.
Are you sure you didn't do a mistake in this sentence?

There's absolutely no problem within the Debian project to forbid using
non-free software. That's what I've signed-up for (ie: "debian will
remain 100% free", aka the FIRST LINE of the social contract), and what
I want, and I'm sure the vast majority of DDs agree.

In the long run, there's going to be significant problems if we open
then Pandora box of using non-free stuff to build Debian. To some
degree, it has already been partially opened.

Indeed, I'm being increasingly frustrated with what's going on in Salsa
in general, and especially when it comes to using Google's
infrastructure. We *must* get out of this. If going through a GR helps
Salsa admins to realize a point of view that I believe I share with a
large amount of people within Debian, then I'm all for it.

On 9/12/19 3:07 PM, Ian Jackson wrote:
> We should resolve this with a GR.  Something like:

I would second that GR. My opinion was that we would need a GR to
enforce things, with this discussion, I'm even more convince we do need
one. My problem was that I'm not as good writing nice English texts as
you are. Good if you can do it.

On 9/12/19 3:07 PM, Ian Jackson wrote:
> Non-Debian services are
> acceptable here so long as they are principally Free Software.

s/principally/fully/

Please, no compromise here. (or is it that I'm badly reading your
English, and that "principally" means something else than in French?)

On 9/12/19 4:37 PM, Enrico Zini wrote:
> I see you keep pushing things with a strong cohercive slant rather
> than working on creating useful and attractive infrastructure to make
> everyone's work easier.

What exactly do you propose here? The Salsa admins look like not
accepting more contributors, neither seem open to suggestions. They just
do "their way". I've countless times wrote to both them and in public
that I'd love to be involved to make things more free. They also refused
to use a packaged version of Gitlab even before it was a thing. They
decided to use Google service, without prior communication about it and
agreement of the community. When some of us pointed out it wasn't ok, it
was strongly rejected, despite any possible offer to use something else
(like Swift storage of other providers).

So, exactly what do you think one can do, given the current situation?
Or are you suggesting someone opens a solution that would compete what's
been done on Salsa? This sounds counter-productive to me.

On 9/12/19 4:51 PM, Ian Jackson wrote:
> The latter is what I am trying to do.  I'm sorry that the opposite is
> occuring.

Ian, you're doing just right. I'm 100% with you on this. We shall not
compromise, we did enough of that already, and in my opinion, we are
already leaning too much on the wrong direction with Salsa.

On 9/13/19 9:39 AM, Enrico Zini wrote:
> Sam showed you how the situation in Debian seems to be different from
> what you understood, and your response was not to acknowledge, try to
> understand, and map the current status quo, but to consider of a GR to
> force the status quo to fit to your expectations.

I very much don't agree on this. If 7% of the packages with VCS fields
are using Github, we *MUST* do something about it. And that's not just
to fit Ian's own malicious agenda, or to please him. If this has to go
through a GR, to make the small minority understand that the vast
majority of us don't agree, then let's do it!

On 9/13/19 9:39 AM, Enrico Zini wrote:
> This cannot be the discussion culture of a group where I can be
> comfortable working with others.

I'm feel sorry to read these lines, though, I don't see how we can
compromise on how much free Debian should be. I'm very surprised read
you're not comfortable working in a group where some of us are pointing
this out. Now, this makes *me* uncomfortable. That's not what I thought
Debian was about then. I thought we all signed up on "Debian will remain
100% free"... How come we don't have a strong consensus on this then?
Have some of us just given-up on software freedom?

Thomas Goirand (zigo)

Re: Git Packaging Round 2: SHOULD Not or MUSt NOT Github

[Russ Allbery]

Thomas Goirand  writes:

> Sorry, WHAAAT ? That's shocking to read this from the DPL.
> Are you sure you didn't do a mistake in this sentence?

> There's absolutely no problem within the Debian project to forbid using
> non-free software.

I use a computer with non-free firmware and push my packaging repositories
to (among other places) GitHub.  Should I therefore not be allowed to do
Debian work?

It's that sort of tool that Sam is talking about.

This is not new.  This is the reason the FSF has at times been mildly
irritated with us: we are willing to make compromises to get Debian to run
on the computers that people actually have, instead of refusing to
reference anything other than software that can only run on a tiny handful
of machines, as much as we would love for more purely free-software
devices to exist.  I feel like interacting with GitHub *among others* (my
primary packaging repositories are on my own personal infrastructure) is
in the same vein, and in the same spirit as the FSF being willing to
support porting of their software to Solaris back in the day.  If free
software is a closed world only usable by people who are already devoted
to free software, we will fail as a political movement.

Even with that disagreement and their additional level of purity here, the
FSF still has not achieved the goal if not using any non-free tools or
non-free software, given that they're still using Intel and AMD
processors, which *absolutely* contain non-free software.

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

Re: Git Packaging Round 2: SHOULD Not or MUSt NOT Github

[Scott Kitterman]

On September 13, 2019 10:51:16 PM UTC, Thomas Goirand  wrote:
>On 9/12/19 2:47 PM, Sam Hartman wrote:
>> 1) there are significant problems we'd run into if we forbid non-free
>tools in
>> Debian work
>
>Sorry, WHAAAT ? That's shocking to read this from the DPL.
>Are you sure you didn't do a mistake in this sentence?
>
>There's absolutely no problem within the Debian project to forbid using
>non-free software. That's what I've signed-up for (ie: "debian will
>remain 100% free", aka the FIRST LINE of the social contract), and what
>I want, and I'm sure the vast majority of DDs agree.
>
>In the long run, there's going to be significant problems if we open
>then Pandora box of using non-free stuff to build Debian. To some
>degree, it has already been partially opened.
>
>Indeed, I'm being increasingly frustrated with what's going on in Salsa
>in general, and especially when it comes to using Google's
>infrastructure. We *must* get out of this. If going through a GR helps
>Salsa admins to realize a point of view that I believe I share with a
>large amount of people within Debian, then I'm all for it.
>
>On 9/12/19 3:07 PM, Ian Jackson wrote:
>> We should resolve this with a GR.  Something like:
>
>I would second that GR. My opinion was that we would need a GR to
>enforce things, with this discussion, I'm even more convince we do need
>one. My problem was that I'm not as good writing nice English texts as
>you are. Good if you can do it.
>
>On 9/12/19 3:07 PM, Ian Jackson wrote:
>> Non-Debian services are
>> acceptable here so long as they are principally Free Software.
>
>s/principally/fully/
>
>Please, no compromise here. (or is it that I'm badly reading your
>English, and that "principally" means something else than in French?)
>
>On 9/12/19 4:37 PM, Enrico Zini wrote:
>> I see you keep pushing things with a strong cohercive slant rather
>> than working on creating useful and attractive infrastructure to make
>> everyone's work easier.
>
>What exactly do you propose here? The Salsa admins look like not
>accepting more contributors, neither seem open to suggestions. They
>just
>do "their way". I've countless times wrote to both them and in public
>that I'd love to be involved to make things more free. They also
>refused
>to use a packaged version of Gitlab even before it was a thing. They
>decided to use Google service, without prior communication about it and
>agreement of the community. When some of us pointed out it wasn't ok,
>it
>was strongly rejected, despite any possible offer to use something else
>(like Swift storage of other providers).
>
>So, exactly what do you think one can do, given the current situation?
>Or are you suggesting someone opens a solution that would compete
>what's
>been done on Salsa? This sounds counter-productive to me.
>
>On 9/12/19 4:51 PM, Ian Jackson wrote:
>> The latter is what I am trying to do.  I'm sorry that the opposite is
>> occuring.
>
>Ian, you're doing just right. I'm 100% with you on this. We shall not
>compromise, we did enough of that already, and in my opinion, we are
>already leaning too much on the wrong direction with Salsa.
>
>On 9/13/19 9:39 AM, Enrico Zini wrote:
>> Sam showed you how the situation in Debian seems to be different from
>> what you understood, and your response was not to acknowledge, try to
>> understand, and map the current status quo, but to consider of a GR
>to
>> force the status quo to fit to your expectations.
>
>I very much don't agree on this. If 7% of the packages with VCS fields
>are using Github, we *MUST* do something about it. And that's not just
>to fit Ian's own malicious agenda, or to please him. If this has to go
>through a GR, to make the small minority understand that the vast
>majority of us don't agree, then let's do it!
>
>On 9/13/19 9:39 AM, Enrico Zini wrote:
>> This cannot be the discussion culture of a group where I can be
>> comfortable working with others.
>
>I'm feel sorry to read these lines, though, I don't see how we can
>compromise on how much free Debian should be. I'm very surprised read
>you're not comfortable working in a group where some of us are pointing
>this out. Now, this makes *me* uncomfortable. That's not what I thought
>Debian was about then. I thought we all signed up on "Debian will
>remain
>100% free"... How come we don't have a strong consensus on this then?
>Have some of us just given-up on software freedom?

The logical conclusion of this line of argument is that I'm only allowed to do 
my packaging work on a computer that doesn't require non-free firmware blobs, 
because doing otherwise is using non-free tools to make Debian.

Are you willing to create a fully free software based CDN and commit to 
maintaining it for the foreseeable future so that we can stop using commercial 
CDN services without harming our users?

Heck, we should probably shut down any mirrors using hardware with non-free 
firmware too.

Scott K

Re: Git Packaging Round 2: SHOULD Not or MUSt NOT Github

[Alf Gaida]

On Sat, 14 Sep 2019 00:51:16 +0200
Thomas Goirand  wrote:

> Sorry, WHAAAT ? That's shocking to read this from the DPL.
> Are you sure you didn't do a mistake in this sentence?
Sorry, Sam is right, he just read and understand the DSC $1 right. If
one work on Debian with non-free tools that will not make the result
non-free. 

> There's absolutely no problem within the Debian project to forbid
> using non-free software. That's what I've signed-up for (ie: "debian
> will remain 100% free", aka the FIRST LINE of the social contract),
> and what I want, and I'm sure the vast majority of DDs agree.
Nope, you signed up that debian will remain 100% free - not for the
tools people work with.  And if debian would forbid the usage of
non-free software to work on some code - i would be the first to leave
the project. I don't use much non-free beside my graphics drivers and
some firmware - but nobody is entitled to forbid me to use bcompare or
github or maybe a commercial editor - nobody has the right to dictate my
tools. Regarding the software: Software has to be free and
should not depend on non-free tools - but to forbid non-free tools if
there are equiv. free interchangeble tools is far over the top.

--- snap  ---

> On 9/13/19 9:39 AM, Enrico Zini wrote:
> > This cannot be the discussion culture of a group where I can be
> > comfortable working with others.  
Fully agree.

> I'm feel sorry to read these lines, though, I don't see how we can
> compromise on how much free Debian should be. I'm very surprised read
> you're not comfortable working in a group where some of us are
> pointing this out. Now, this makes *me* uncomfortable. That's not
> what I thought Debian was about then. I thought we all signed up on
> "Debian will remain 100% free"... How come we don't have a strong
> consensus on this then? Have some of us just given-up on software
> freedom?
And again - i'm not comfortable with this reading of §1 - like it or
not - if your opinion and reading is the consensus and supported by the
majority in debian it will be time for me to leave as fast as i can and
don't look back. Would make me a bit sorry for the then wasted years -
but hey, life goes on. 

And i subscribed the same things as you do and had no problem to do so.
I'm all for free software, i spend the very most of my spare time to it
- not only in debian. But if the official reading will be your
  interpretation: Sorry, i'm out, can't and will not follow - in that
  special case there will be some projects that fit my needs better.

Cheers Alf

PS: Please read this in the context of my former posts - this
discussion would not happend if all the packages are hosted used debian
infrastructure - and i'm dead set against using non-free infra in
debian. One exception: I don't consider firmware and processor patches
as Software in the sense of DFSG - so the servers we are running should
be allowed to use the newest firmware and processor patches they need)

Cheers Alf

> Thomas Goirand (zigo)
> 



-- 
Alf Gaida
BDBF C688 EFAD BA89 5A9F  464B CD28 0A0B 4D72 827C

Bug#820036: I have good news for this E-Mail ID user

[Arango Carlos]

You are the heir to our late Canadian gold merchant $8.2 Million 
Canadian dollar.

Re: Git Packaging Round 2: SHOULD Not or MUSt NOT Github

[Pirate Praveen]

On 2019, സെപ്റ്റംബർ 14 4:21:16 AM IST, Thomas Goirand  wrote:
>On 9/12/19 2:47 PM, Sam Hartman wrote:
>> 1) there are significant problems we'd run into if we forbid non-free
>tools in
>> Debian work
>
>Sorry, WHAAAT ? That's shocking to read this from the DPL.
>Are you sure you didn't do a mistake in this sentence?
>
>There's absolutely no problem within the Debian project to forbid using
>non-free software. That's what I've signed-up for (ie: "debian will
>remain 100% free", aka the FIRST LINE of the social contract), and what
>I want, and I'm sure the vast majority of DDs agree.
>
>In the long run, there's going to be significant problems if we open
>then Pandora box of using non-free stuff to build Debian. To some
>degree, it has already been partially opened.
>
>Indeed, I'm being increasingly frustrated with what's going on in Salsa
>in general, and especially when it comes to using Google's
>infrastructure. We *must* get out of this. If going through a GR helps
>Salsa admins to realize a point of view that I believe I share with a
>large amount of people within Debian, then I'm all for it.
>
>On 9/12/19 3:07 PM, Ian Jackson wrote:
>> We should resolve this with a GR.  Something like:
>
>I would second that GR. My opinion was that we would need a GR to
>enforce things, with this discussion, I'm even more convince we do need
>one. My problem was that I'm not as good writing nice English texts as
>you are. Good if you can do it.
>
>On 9/12/19 3:07 PM, Ian Jackson wrote:
>> Non-Debian services are
>> acceptable here so long as they are principally Free Software.
>
>s/principally/fully/
>
>Please, no compromise here. (or is it that I'm badly reading your
>English, and that "principally" means something else than in French?)
>
>On 9/12/19 4:37 PM, Enrico Zini wrote:
>> I see you keep pushing things with a strong cohercive slant rather
>> than working on creating useful and attractive infrastructure to make
>> everyone's work easier.
>
>What exactly do you propose here? The Salsa admins look like not
>accepting more contributors, neither seem open to suggestions. They
>just
>do "their way". I've countless times wrote to both them and in public
>that I'd love to be involved to make things more free. They also
>refused
>to use a packaged version of Gitlab even before it was a thing. They
>decided to use Google service, without prior communication about it and
>agreement of the community. When some of us pointed out it wasn't ok,
>it
>was strongly rejected, despite any possible offer to use something else
>(like Swift storage of other providers).
>
>So, exactly what do you think one can do, given the current situation?
>Or are you suggesting someone opens a solution that would compete
>what's
>been done on Salsa? This sounds counter-productive to me.
>
>On 9/12/19 4:51 PM, Ian Jackson wrote:
>> The latter is what I am trying to do.  I'm sorry that the opposite is
>> occuring.
>
>Ian, you're doing just right. I'm 100% with you on this. We shall not
>compromise, we did enough of that already, and in my opinion, we are
>already leaning too much on the wrong direction with Salsa.
>
>On 9/13/19 9:39 AM, Enrico Zini wrote:
>> Sam showed you how the situation in Debian seems to be different from
>> what you understood, and your response was not to acknowledge, try to
>> understand, and map the current status quo, but to consider of a GR
>to
>> force the status quo to fit to your expectations.
>
>I very much don't agree on this. If 7% of the packages with VCS fields
>are using Github, we *MUST* do something about it. And that's not just
>to fit Ian's own malicious agenda, or to please him. If this has to go
>through a GR, to make the small minority understand that the vast
>majority of us don't agree, then let's do it!

I will also support such a GR. I started packaging gitlab so we don't have to 
compromise on ease of use compared to github.

>On 9/13/19 9:39 AM, Enrico Zini wrote:
>> This cannot be the discussion culture of a group where I can be
>> comfortable working with others.
>
>I'm feel sorry to read these lines, though, I don't see how we can
>compromise on how much free Debian should be. I'm very surprised read
>you're not comfortable working in a group where some of us are pointing
>this out. Now, this makes *me* uncomfortable. That's not what I thought
>Debian was about then. I thought we all signed up on "Debian will
>remain
>100% free"... How come we don't have a strong consensus on this then?
>Have some of us just given-up on software freedom?

>Thomas Goirand (zigo)

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

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

[Shengjing Zhu]

On Fri, Sep 13, 2019 at 7:05 PM Simon Richter  wrote:
>
> Hi,
>
> On Fri, Sep 13, 2019 at 12:28:23PM +0200, Marco d'Itri wrote:
>
> > > Note that by way of counterargument, Google and its services have
> > > been blocked in mainland China by the Great Firewall for nearly a
> > > decade now, so I question whether there is really such a thing as
> > > "too big to block."
>
> > This is a false dichotomy: not all nation states are willing to go to
> > the extreme lengths as China.
>
> Also, China cannot block Github, because they have no equivalent, and even
> if they did, it wouldn't have the same content. Google is too easily
> replicated, because they have no immediate contributors.
>
> I expect that China will set up a proxy service with clones of all relevant
> Github repositories soon to keep read-only access to free software around
> but inhibit organizing through shared documents.
>
> CloudFlare has too many services behind them that are important for the
> economy and not replicable, so they are in a better position than Github
> here.
>

Really?

It's too native have such thoughts. It's never "too big to block".
It's "not worth to block" if it's not too big. If you are in the
"real" censorship environment, you would know how meaningless it is to
rely on some "big" third-partys.

Please don't in name of censorship-resistant.

-- 
Shengjing Zhu

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

[Shengjing Zhu]

On Sat, Sep 14, 2019 at 12:25 PM Shengjing Zhu  wrote:
> It's too native have such thoughts. It's never "too big to block".

s/native/naive/

-- 
Shengjing Zhu

Re: Git Packaging Round 2: SHOULD Not or MUSt NOT Github

[Balasankar "Balu" C]

Hi,

On 14/9/19 4:21 AM, Thomas Goirand wrote:
> On 9/12/19 2:47 PM, Sam Hartman wrote:
>> 1) there are significant problems we'd run into if we forbid non-free tools 
>> in
>> Debian work
> 
> Sorry, WHAAAT ? That's shocking to read this from the DPL.
> Are you sure you didn't do a mistake in this sentence?
> 
> There's absolutely no problem within the Debian project to forbid using
> non-free software.

Debian project using non-free software for day-to-day functioning is
different that Debian contributors using non-free software.

If Debian project was using GitHub Enterprise or GitLab Enterprise
Edition for hosting all the source code and demanded all packages in
Debian to use that for development, that is an issue.

But it shouldn't matter to the project that I do my packaging work in
GitLab.com or GitHub.com because as far as Debian is concerned, as long
as others can contribute without having an account in that service - I
should not be forbidden using them. That is, if I come in and say "I
won't accept any patches submitted over BTS, but only GitHub PRs", the
project has every right to kick the package out of Debian or fork it.
But as long as I continue supporting people using BTS, I should be fine
using whatever I want as my primary platform.

Until Salsa repo is a first class citizen (that is, something
unavoidable and a mandatory requirement) in Debian development , we
can't mandate on using that. AFAIK, BTS is the official ("official", not
"mandatory") way to develop Debian because it is the only thing
mentioned in policy (I don't know if we explicitly say to use BTS for
everything, but we do mention BTS few times in the policy document).

 That's what I've signed-up for (ie: "debian will
> remain 100% free", aka the FIRST LINE of the social contract), and what
> I want, and I'm sure the vast majority of DDs agree.

Yes, what Debian project uses and produces must be 100% free. But I
won't enforce anyone to use Salsa unless there is a project-wide
consensus that packaging of every package must happen in 
(replace  with any service).

And personally, I am not sure how such a decision will impact the Project.

> 
> In the long run, there's going to be significant problems if we open
> then Pandora box of using non-free stuff to build Debian.

Agree with this, if it is referring to the technical meaning of "build"
(a package depending on a non-free library to be compiled), not the
general one (that is "gadgets or devices or tools a person uses to do
packaging work).

> Indeed, I'm being increasingly frustrated with what's going on in Salsa
> in general, and especially when it comes to using Google's
> infrastructure. We *must* get out of this. If going through a GR helps
> Salsa admins to realize a point of view that I believe I share with a
> large amount of people within Debian, then I'm all for it.

I agree - if we as a Project feels like Salsa is being administered in a
manner we don't prefer, we should clarify it via a GR, and decide how we
can help Salsa admins on this.
> 
> On 9/12/19 4:37 PM, Enrico Zini wrote:
>> I see you keep pushing things with a strong cohercive slant rather
>> than working on creating useful and attractive infrastructure to make
>> everyone's work easier.
> 
> What exactly do you propose here? The Salsa admins look like not
> accepting more contributors, neither seem open to suggestions. They just
> do "their way". I've countless times wrote to both them and in public
> that I'd love to be involved to make things more free. They also refused
> to use a packaged version of Gitlab even before it was a thing. They
> decided to use Google service, without prior communication about it and
> agreement of the community. When some of us pointed out it wasn't ok, it
> was strongly rejected, despite any possible offer to use something else
> (like Swift storage of other providers).

This feels like a serious problem to me. Could you also share links, please?

> On 9/13/19 9:39 AM, Enrico Zini wrote:
>> Sam showed you how the situation in Debian seems to be different from
>> what you understood, and your response was not to acknowledge, try to
>> understand, and map the current status quo, but to consider of a GR to
>> force the status quo to fit to your expectations.
> 
> I very much don't agree on this. If 7% of the packages with VCS fields
> are using Github, we *MUST* do something about it. And that's not just
> to fit Ian's own malicious agenda, or to please him. If this has to go
> through a GR, to make the small minority understand that the vast> majority 
> of us don't agree, then let's do it!

So will the GR be
"You must not do any sort of contribution to Debian using non-free
software/hardware"

or

"You can use anything you want to contribute to Debian, but there should
be a way for other people to contribute to your work in Debian without
compromising on their freedom" ? (This translates to my words in the
beginning of this reply - patches over BTS must not be rejecte