Re: Git Packaging Round 2: When to Salsa

[Nikolaus Rath]

On Sep 08 2019, Sam Hartman  wrote:
> Hopefully you will choose to monitor merge requests for your
> repository.  If not, turn off merge requests.

Monitor *and respond to* might be a better phrasing..?

Best,
Nikolaus
-- 
GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«

Re: Bug#939421: O: gdisk -- GPT fdisk text-mode partitioning tool

[Jonathan Carter]

On 2019/09/05 12:27, Jonathan Carter wrote:
> If I'm correct and fdisk does indeed not let you do that then I'd rather
> maintain gdisk than have it removed from the archives since I somewhat
> rely on it for some of my users who have crappy^W more lower-end laptops.

I adopted this package today. It's description wasn't very clear on what
you'd use it for so I updated it to include some of its common use cases:

"""
 GPT fdisk (aka gdisk) is a text-mode partitioning
 tool that provides utilities for Globally Unique
 Identifier (GUID) Partition Table (GPT) disks.
 .
 Features:
 .
  - Edit GUID partition table definitions
  - In place conversion of BSD disklabels to GPT
  - In place conversion of MBR to GPT
  - In place conversion of GPT to MBR
  - Create hybrid MBR/GPT layouts
  - Repair damaged GPT data structures
  - Repair damaged MBR structures
  - Back up GPT data to a file (and restore from file)
"""

Probably not perfect but it is an improvement, packaging is on salsa now
so any further improvements are welcome there.

https://salsa.debian.org/debian/gdisk

-Jonathan

-- 
  ⢀⣴⠾⠻⢶⣦⠀  Jonathan Carter (highvoltage) 
  ⣾⠁⢠⠒⠀⣿⡁  Debian Developer - https://wiki.debian.org/highvoltage
  ⢿⡄⠘⠷⠚⠋   https://debian.org | https://jonathancarter.org
  ⠈⠳⣄  Be Bold. Be brave. Debian has got your back.

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

[Bjørn Mork]

Ondřej Surý  writes:

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

And also section 8 of
https://tools.ietf.org/html/draft-reid-doh-operator-00


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

I agree, FWIW. User consent is required.

I for one, do trust my ISPs a lot more than I trust Cloudflare or
Google, simply based on the jurisdiction.

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


Bjørn

Bug#939857: ITP: golang-github-alexflint-go-filemutex -- processes synchronization library

[Dmitry Smirnov]

Package: wnpp
Severity: wishlist
Owner: Dmitry Smirnov 
X-Debbugs-CC: debian-devel@lists.debian.org, 
pkg-go-maintain...@lists.alioth.debian.org
Control: block 930900 by -1

   Package name: golang-github-alexflint-go-filemutex
Version: 0.0+git20171028
Upstream Author: Alex Flint
License: Expat and BSD-3-Clause
URL: https://github.com/alexflint/go-filemutex
Vcs-Browser: 
https://salsa.debian.org/go-team/packages/golang-github-alexflint-go-filemutex
Description: processes synchronization library
 FileMutex is similar to sync.RWMutex, but also synchronizes across
 processes.  On Linux, OSX, and other POSIX systems it uses the flock
 system call.


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

Re: Git Packaging Round 2: When to Salsa

[Colin Watson]

On Mon, Sep 09, 2019 at 10:22:03AM +0100, Nikolaus Rath wrote:
> On Sep 08 2019, Sam Hartman  wrote:
> > Hopefully you will choose to monitor merge requests for your
> > repository.  If not, turn off merge requests.
> 
> Monitor *and respond to* might be a better phrasing..?

I don't think I can promise to respond to every merge request on my
packages any more than I can promise to respond to every bug report.
It's fine for us to say that this sort of thing should actually result
in somebody getting some kind of notification rather than going into an
effective black hole where nobody sees it except by chance; but
requiring a response in all cases is effectively an SLA ("service level
agreement"), and I can't realistically give SLAs unless I'm being paid
for it.

-- 
Colin Watson   [cjwat...@debian.org]

Bug#939867: ITP: golang-github-seccomp-containers-golang -- libseccomp mappings in Golang

[Dmitry Smirnov]

Package: wnpp
Severity: wishlist
Owner: Dmitry Smirnov 
X-Debbugs-CC: debian-devel@lists.debian.org, 
pkg-go-maintain...@lists.alioth.debian.org
Control: block 930440 by -1

   Package name: golang-github-seccomp-containers-golang
Version: 0.3.1-1
License: Apache-2.0
URL: https://github.com/seccomp/containers-golang
Vcs-Browser: 
https://salsa.debian.org/go-team/packages/golang-github-seccomp-containers-golang
Description: libseccomp mappings in Golang
 Golang libraries used by container runtimes to generate and load seccomp
 mappings into the kernel.
 .
 seccomp (short for secure computing mode) is a BPF based syscall filter
 language presenting conventional function-call based filtering interface.


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

Bug#939870: ITP: golang-github-buger-goterm -- advanced terminal output in Golang

[Dmitry Smirnov]

Package: wnpp
Severity: wishlist
Owner: Dmitry Smirnov 
X-Debbugs-CC: debian-devel@lists.debian.org, 
pkg-go-maintain...@lists.alioth.debian.org
Control: block 930440 by -1

   Package name: golang-github-buger-goterm
Version: 0.0~git20181115
Upstream Author: Leonid Bugaev
License: Expat
URL: https://github.com/buger/goterm
Vcs-Browser: 
https://salsa.debian.org/go-team/packages/golang-github-buger-goterm
Description: advanced terminal output in Golang
 This library provides basic building blocks for building advanced console
 UIs.


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

Re: Git Packaging Round 2: When to Salsa mirror

[Ansgar]

Geert Stappers writes:
> On Sun, Sep 08, 2019 at 10:05:17PM -0700, Russ Allbery wrote:
>> Higher chance that the repository won't go away.
>
> Where is Alioth? As retoric question.

The repositories on Alioth weren't lost and can still be found archived
on https://alioth-archive.debian.org/

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

Arguably in Git everything but the maintainer's local repository might
be a mirror.  This was even called a security feature as hash collisions
might need to be sneaked in there to get included in release tarballs[1].

Ansgar

  [1] 
https://public-inbox.org/git/pine.lnx.4.58.0504291221250.18...@ppc970.osdl.org/

Re: Git Packaging Round 2: When to Salsa

[Ansgar]

Sam Hartman writes:
> 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 .

This allows everyone to do arbitrary changes and presumably upload the
package.  That is quite a large change that I'm not sure everyone likes.

+---
| Direct commits to repositories in the Debian group by any Debian
| developer are implicitly welcome. No pre-commit coordination
| (e.g. merge-request or mail) is expected.
+---[ 
https://wiki.debian.org/Salsa/Doc#Collaborative_Maintenance:_.22Debian.22_group 
]

Ansgar

Re: Git Packaging Round 2: When to Salsa

[Sam Hartman]

> "Ansgar" == Ansgar   writes:

Ansgar> Sam Hartman writes:
>> 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 .

Ansgar> This allows everyone to do arbitrary changes and presumably
Ansgar> upload the package.  That is quite a large change that I'm
Ansgar> not sure everyone likes.

I'm sure some people don't like it.  What I'm hoping to get here is
comments on whether I've correctly judged consensus that the rough
consensus is we're OK with that as a general recommendation.

--Sam

Re: Git Packaging Round 2: When to Salsa

[Jonas Smedegaard]

Quoting Sam Hartman (2019-09-09 19:49:25)
> > "Ansgar" == Ansgar   writes:
> 
> Ansgar> Sam Hartman writes:
> >> 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 .
> 
> Ansgar> This allows everyone to do arbitrary changes and presumably
> Ansgar> upload the package.  That is quite a large change that I'm
> Ansgar> not sure everyone likes.
> 
> I'm sure some people don't like it.  What I'm hoping to get here is
> comments on whether I've correctly judged consensus that the rough
> consensus is we're OK with that as a general recommendation.

It is not my impression that there is a general concensus on that, no.

I think there is a general consensus on working in teams, and therefore 
using git repos belonging to teams - but not to use that one giant 
"team" called "debian".

Yes, my impression on this might be biased by my own personal opinion.  
Perhaps it makes sense to look at statistics of how much the debian part 
of salsa is currently used, compared ot other teams' get areas.  Sorry, 
I don't know how to extract such statistics, but am sure some do.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: Git Packaging Round 2: When to Salsa

[Sam Hartman]

> "Jonas" == Jonas Smedegaard  writes:


Jonas> I think there is a general consensus on working in teams, and
Jonas> therefore using git repos belonging to teams - but not to use
Jonas> that one giant "team" called "debian".

What would you recommend people do if they have a package that doesn't
fit into an existing team.

--Sam

win32-loader: Dropping Win ME/98/95 support, digital signing, Windows Store

[Thomas Gaugler]

Hi,

win32-loader is a Windows (Win32) executable to ease the installation of
Debian on a PC running Windows.

The Nullsoft Scriptable Install System (NSIS) is used to create the
win32-loader targeting character sets that are native to Windows
ME/98/95 (also known as x86-ansi installer). This leads to code page
conversion issues for example as described in Bug #939151.

Therefore I intend to switch win32-loader from an x86-ansi to an
x86-unicode installer. The drawback would be that Windows versions prior
Windows XP would no longer be supported.

I have no idea how many installations of Windows ME/98/85 are still
being used out there in the wild. However independent of this number
there might be reasons to keep respectively restore Windows ME/98/95
support for win32-loader. If you are aware of any reason then please let
me know.

Furthermore I would like to increase user confidence and trust by
digitally signing the win32-loader executable. As a side effect user
friction could be reduced. For example Microsoft SmartScreen [1] warns
the user with the message: "Windows Defender SmartScreen prevented an
unrecognized app from starting.". How could win32-loader be enhanced
with a Debian code signing certificate?

Last but not least I wonder if there would be any value in distributing
win32-loader via the Windows Store [2]. The idea stems from the
availability of "Debian for the Windows Subsystem" in the Windows Store.

Cheers,
Thomas

[1] https://en.wikipedia.org/wiki/Microsoft_SmartScreen
[2] https://en.wikipedia.org/wiki/Microsoft_Store_(digital)

--
I welcome VSRE emails. See http://vsre.info/

Re: win32-loader: Dropping Win ME/98/95 support, digital signing, Windows Store

[Bastian Blank]

On Mon, Sep 09, 2019 at 10:01:47PM +0200, Thomas Gaugler wrote:
> Furthermore I would like to increase user confidence and trust by
> digitally signing the win32-loader executable. As a side effect user
> friction could be reduced. For example Microsoft SmartScreen [1] warns
> the user with the message: "Windows Defender SmartScreen prevented an
> unrecognized app from starting.". How could win32-loader be enhanced
> with a Debian code signing certificate?

I assume the secure boot signing stuff should be able to do that.  You
might want to ask ansgar@.

> Last but not least I wonder if there would be any value in distributing
> win32-loader via the Windows Store [2]. The idea stems from the
> availability of "Debian for the Windows Subsystem" in the Windows Store.

How does this store stuff work?  Any contractual agreement and so one
needs to be handled by SPI.  SPI is a Microsoft Partner and got the
"debian" publisher for all Azure stuff already.  I should be able to
help with that.

Bastian

-- 
A Vulcan can no sooner be disloyal than he can exist without breathing.
-- Kirk, "The Menagerie", stardate 3012.4

Bug#939905: ITP: golang-github-containers-psgo -- ps(1) AIX-format compatible Golang library

[Dmitry Smirnov]

Package: wnpp
Severity: wishlist
Owner: Dmitry Smirnov 
X-Debbugs-CC: debian-devel@lists.debian.org, 
pkg-go-maintain...@lists.alioth.debian.org
Control: block 930440 by -1

   Package name: golang-github-containers-psgo
Version: 1.3.1
License: Apache-2.0
URL: https://github.com/containers/psgo
Vcs-Browser: 
https://salsa.debian.org/go-team/packages/golang-github-containers-psgo
Description: ps(1) AIX-format compatible Golang library
 Psgo is a ps(1) AIX-format compatible golang library extended with various
 descriptors useful for displaying container-related data.
 .
 The idea behind the library is to provide an easy to use way of extracting
 process-related data, just as ps(1) does. The problem when using ps(1) is
 that the ps format strings split columns with whitespaces, making the
 output nearly impossible to parse. It also adds some jitter as we have to
 fork and execute ps either in the container or filter the output
 afterwards, further limiting applicability.
 .
 This library aims to make things a bit more comfortable, especially for
 container runtimes, as the API allows to join the mount namespace of a
 given process and will parse /proc and /dev/ from there.


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

Re: Git Packaging Round 2: When to Salsa

[David Bremner]

Sam Hartman  writes:

>> "Jonas" == Jonas Smedegaard  writes:
>
>
> Jonas> I think there is a general consensus on working in teams, and
> Jonas> therefore using git repos belonging to teams - but not to use
> Jonas> that one giant "team" called "debian".
>
> What would you recommend people do if they have a package that doesn't
> fit into an existing team.
>
> --Sam

One option is putting them in their own user namespace. This is
generally my preferred option for packages that are not maintained as
part of a team. I think the option of merge requests reduces the need to
give out direct push access.

d

Re: Git Packaging Round 2: When to Salsa

[Sam Hartman]

> "David" == David Bremner  writes:

David> Sam Hartman  writes:
>>> "Jonas" == Jonas Smedegaard  writes:
>> 
>> 
Jonas> I think there is a general consensus on working in teams, and
Jonas> therefore using git repos belonging to teams - but not to use
Jonas> that one giant "team" called "debian".
>> 
>> What would you recommend people do if they have a package that
>> doesn't fit into an existing team.
>> 
>> --Sam

David> One option is putting them in their own user namespace. This
David> is generally my preferred option for packages that are not
David> maintained as part of a team. I think the option of merge
David> requests reduces the need to give out direct push access.

I tried to cover the disadvantages of this in the original mail:

* Works poorly when maintainership changes

* Works poorly when account status changes

I am sure you're aware of these, but I want to make sure they are on the
table.
And obviously, the debian group has disadvantages:

* works poorly if you don't want everyone having push access

  * Because you don't want to be that open with your package

  * Because you are mirroring or something where having push access will
break things

There are a number of ways forward:

1) Add a recommendation for people who don't want to give push access to
all developers.  Personal namespaces is the only option I've seen so
far.

2) Only recommend personal namespaces and never debian

3) Note both options but not make a recommendation between them

4) Something along the lines of the current text; Jonas has explicitly
disagreed with this approach

5) Make no recommendations in this space

While I've been monitoring a lot of discussions, this issue is one where
we'd need significantly more feedback than we've received so far for me
to call a consensus.

--Sam

Re: Git Packaging Round 2: When to Salsa

[Russ Allbery]

Sam Hartman  writes:

> There are a number of ways forward:

> 1) Add a recommendation for people who don't want to give push access to
> all developers.  Personal namespaces is the only option I've seen so
> far.

> 2) Only recommend personal namespaces and never debian

> 3) Note both options but not make a recommendation between them

> 4) Something along the lines of the current text; Jonas has explicitly
> disagreed with this approach

> 5) Make no recommendations in this space

> While I've been monitoring a lot of discussions, this issue is one where
> we'd need significantly more feedback than we've received so far for me
> to call a consensus.

I think using the debian namespace is the right default, particularly when
we view it through the lens of what's best for the project.

Think of it this way: we have a new Debian package maintained by someone
who's maybe new to the project.  What kind of experience do we want them
to have by default, and how do we want to store their work to reduce the
risk of various failure modes with new maintainers?

My arguments in favor of the debian namespace:

1. This has the lowest bar of entry: you don't have to set up a namespace
   or think about access control.

2. This has the lowest friction for collaborative work and onboarding new
   contributors.

3. Anyone who comes from a tech company / Silicon Valley development
   environment is probably going to already be used to this style of
   collective ownership (along with politeness conventions about not
   messing with other people's stuff unless you have talked to them or
   know what you're doing), since this is an extremely common development
   model there, and this will feel natural.

4. This has the least risk for the project if the person doing the work
   disappears.  We don't have to move the Git repository, change ACLs,
   recover history from somewhere else, etc.  Anyone else can pick up work
   as needed in the same place.

5. We can easily make mass changes to these packages, which is something
   we've not done much of historically but which would be a powerful new
   tool.  It would be even more powerful if we could do that for all
   packages, of course, but that has more social tradeoffs, and it's still
   useful to be able to do mass changes to a class of packages that may be
   the ones with the least "attached" maintainers to the project who may
   not be following project-wide discussions.

Obviously, we cannot and should not *require* using the debian namespace,
and anyone who wants to can certainly create their own namespaces.  But I
think it's important to note here that folks like Jonas are not the target
audience for these recommendations.  Anyone who, like him, already is
doing Debian packaging and already knows how Debian works can continue to
manage their packages however they want.  They already know the onboarding
costs and are comfortable with them, the project has a track record with
them and knows they're not likely to disappear, etc.

I'm also a little bit uncomfortable with putting some of my packages
(particularly the ones for which I'm also upstream) into the debian
namespace because I want more control.  (This may be an unproductive
emotional reaction; I may decide later that this is wrong.  But it was my
first reaction.)  But I don't think we should look at this through whether
it matches what I, or Jonas, or David, or someone else already deeply
enmeshed in Debian would do.  We should be choosing a default
recommendation anticipating the mindset of a new developer instead.

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

Re: Git Packaging Round 2: When to Salsa

[Scott Kitterman]

On September 10, 2019 1:26:35 AM UTC, Sam Hartman  wrote:
>> "David" == David Bremner  writes:
>
>David> Sam Hartman  writes:
>>>> "Jonas" == Jonas Smedegaard  writes:
>>> 
>>> 
>   Jonas> I think there is a general consensus on working in teams, and
>   Jonas> therefore using git repos belonging to teams - but not to use
>Jonas> that one giant "team" called "debian".
>>> 
>>> What would you recommend people do if they have a package that
>>> doesn't fit into an existing team.
>>> 
>>> --Sam
>
>David> One option is putting them in their own user namespace. This
>David> is generally my preferred option for packages that are not
>David> maintained as part of a team. I think the option of merge
>David> requests reduces the need to give out direct push access.
>
>I tried to cover the disadvantages of this in the original mail:
>
>* Works poorly when maintainership changes
>
>* Works poorly when account status changes
>
>I am sure you're aware of these, but I want to make sure they are on
>the
>table.
>And obviously, the debian group has disadvantages:
>
>* works poorly if you don't want everyone having push access
>
>  * Because you don't want to be that open with your package
>
> * Because you are mirroring or something where having push access will
>break things
>
>There are a number of ways forward:
>
>1) Add a recommendation for people who don't want to give push access
>to
>all developers.  Personal namespaces is the only option I've seen so
>far.
>
>2) Only recommend personal namespaces and never debian
>
>3) Note both options but not make a recommendation between them
>
>4) Something along the lines of the current text; Jonas has explicitly
>disagreed with this approach
>
>5) Make no recommendations in this space
>
>While I've been monitoring a lot of discussions, this issue is one
>where
>we'd need significantly more feedback than we've received so far for me
>to call a consensus.

I don't think your alleged works poorly for using your own namespace are real 
problems.  Since git has no single central repository moving is as simple as a 
clone and then push it to the new location.  If there are multiple instances of 
a package on salsa (which can happen for any number of reasons) the "official" 
one is the one the Vcs-* point to.

For other VCS I think those would be valid concerns, but for git they can be 
trivially avoided.

Scott K

Re: win32-loader: Dropping Win ME/98/95 support, digital signing, Windows Store

[Paul Wise]

On Tue, Sep 10, 2019 at 4:18 AM Thomas Gaugler wrote:

> Therefore I intend to switch win32-loader from an x86-ansi to an
> x86-unicode installer. The drawback would be that Windows versions prior
> Windows XP would no longer be supported.

Would it be possible to build both versions in order to keep support
for ancient Windows versions?

> Furthermore I would like to increase user confidence and trust by
> digitally signing the win32-loader executable. How could
> win32-loader be enhanced with a Debian code signing certificate?

We have a code signing certificate for signing our shim binaries for
use with secure boot, probably a similar approach will be useful for
win32-loader.

https://wiki.debian.org/SecureBoot/Discussion

> Last but not least I wonder if there would be any value in distributing
> win32-loader via the Windows Store [2].

Sounds good to me.

OTOH expanding the visibility of win32-loader could introduce
significant user support load if people don't understand what the app
does, download and run it, make their Windows computer be any
different to normal (including introducing black BOOTMGR/NTLDR screens
for eg) and then come complaining to Debian or leaving bad reviews on
the Windows Store.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

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

[Florian Lohoff]

On Mon, Sep 09, 2019 at 03:31:37PM +0200, Bjørn Mork wrote:
> I for one, do trust my ISPs a lot more than I trust Cloudflare or
> Google, simply based on the jurisdiction.

There are tons of setups which are fine tuned for latency because they
are behind sat links etc or low bandwidth landlines. They have dns
caches with prefetching to reduce typical resolve latency down to sub
milliseconds although your RTT to google/cloudflare is >1000ms.

Switching from your systems resolver fed by DHCP to DoH in Firefox will
make the resolve latency go from sub ms to multiple seconds as the
HTTP/TLS handshake will take multiple RTT. This will effectively break
ANY setup behind Sat links e.g. for example all cruise ships at
sea.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The 🐈 ran after a 🐁, but the 🐁 ran away


signature.asc
Description: PGP signature

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

[Ondřej Surý]

> On 9 Sep 2019, at 15:31, Bjørn Mork  wrote:
> 
> I for one, do trust my ISPs a lot more than I trust Cloudflare or
> Google, simply based on the jurisdiction.

While I still strongly agree with you on this one (even though I think all
major ISPs here are scumbags, especially the incumbent), I still strongly
think we should not have this debate here, and we should turn this around
the usual Debian policy - to not send data to 3rd party without explicit user
content and defaulting to not doing so.

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