Re: git & Debian packaging sprint report

[Scott Kitterman]

On July 15, 2019 8:50:48 PM UTC, Russ Allbery  wrote:
>Ansgar Burchardt  writes:
>
>> SHA-1 isn't going to get stronger in the future.  The TLS world has
>> already moved on, OpenPGP is still in the slow process to move on,
>> Release/Packages stopped using it[1], there is no reason to continue
>> using it.
>
>Well, the reason to continue using it is that Git uses it and we use
>Git,
>and it may simplify the workflow.
>
>You're not wrong, of course, but preimage attacks are very hard.  MD5
>is
>still probably robust against preimage attacks, let alone SHA-1.  By
>all
>means, let's future-proof as much as possible, but I'm not sure
>worrying
>about SHA-1 preimage resistance is the most important design principle
>in
>this case.  At some point, Git itself will switch away from SHA-1, and
>we
>can then obviously follow.
...
Except that we have different requirements than git.  Git isn't looking for 
security properties from SHA-1, so it's highly likely it'll meet their accident 
avoidance requirements long after it's no longer appropriate for security 
related assertions.

I don't think adding more SHA-1 in a security sensitive context is a good plan.

Scott K

Re: git & Debian packaging sprint report

[Ben Hutchings]

On Mon, 2019-07-15 at 20:54 +0200, Ansgar Burchardt wrote:
> Russ Allbery writes:
> > If so, I think that security model is roughly equivalent to the automatic
> > signing of binary packages by buildds, so probably doesn't introduce a new
> > vulnerability,
> 
> It doesn't rely on strong cryptographic hashes to guarantee integrity.
> To quote Wikipedia:
> 
> +---
> > Revision control systems such as Git, Mercurial, and Monotone use
> > SHA-1 not for security but to identify revisions and to ensure that
> > the data has not changed due to accidental corruption.
> +---[ https://en.wikipedia.org/wiki/SHA-1#Data_integrity ]
> 
> But developers could instead just sign artifacts using a strong
> cryptographic hash that will be included in the source package; for
> example the .orig.tar and .debian.tar which can be made reproducible
> (git-archive is supposed to be reproducible; compression might not be so
> just sign the uncompressed version).
[...]

There is already a convention for adding tarball signatures using git
notes, though it would need to be adapted for the two tarballs in non-
native packages.

See

and the "git-archive-signer" script in
.

Ben.

-- 
Ben Hutchings
If God had intended Man to program,
we'd have been born with serial I/O ports.



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

Re: systemd services that are not equivalent to LSB init scripts

[Ben Hutchings]

On Mon, 2019-07-15 at 00:00 +0200, Martin Steigerwald wrote:
> Hello.
> 
> Theodore Ts'o - 14.07.19, 22:07:
> > So requiring support of non-systemd ecosystems is in general, going to
> > require extra testing.  In the case of cron/systemd.timers, this
> > means testing and/or careful code inspection to make sure the
> > following cases work:
> > 
> > * systemd && cron
> > * systemd && !cron
> > * !systemd && cron
> > 
> > Support of non-systemd ecosystems is not going to be free, and some
> > cases, it is not going to be fun, something which many have asserted
> > should be something we should be striving for.  The challenge is how
> > do we develop the consensus to decide whether or not we force
> > developers to pay this cost.
> 
> I believe forcing someone who does volunteer work by maintaining 
> packages for Debian is not going to work out. Or even more so: I do not 
> see how Debian project could force developers. The only effective way to 
> force anything would be to threaten with loosing membership status or 
> privileged. But I would not go that route as I see it as destructive 
> one.
[...]

We can't force individual developers to do anything, and yet we manage
to release with a large number of packages that mostly follow policy. 
If it's our policy that packages must support cron (where applicable)
then a failure to do so can be fixed by any developer, following the
usual process.

Ben.

-- 
Ben Hutchings
If God had intended Man to program,
we'd have been born with serial I/O ports.




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

Bug#932154: ITP: golang-github-briandowns-spinner -- Go library for providing a terminal spinner/progress indicator

[Nobuhiro Iwamatsu]

Package: wnpp
Severity: wishlist
Owner: Nobuhiro Iwamatsu 

* Package name: golang-github-briandowns-spinner
  Version : 1.6.1
  Upstream Author : Brian Downs 
* URL : https://github.com/briandowns/spinner
* License : Apache-2.0
  Programming Lang: Go
  Description : Go library for providing a terminal spinner/progress 
indicator

 golang-github-briandowns-spinner-dev is a simple library to add a spinner or
 progress indicator to any terminal application.
 .
 This provides not only ascii art's spinners, but also spinners using Unicode 
emoji.

Bug#932153: ITP: golang-github-caarlos0-env -- Go library for parse environment variables to structs

[Nobuhiro Iwamatsu]

Package: wnpp
Severity: wishlist
Owner: Nobuhiro Iwamatsu 

* Package name: golang-github-caarlos0-env
  Version : 6.0.0
  Upstream Author : Carlos Alexandro Becker
* URL : https://github.com/caarlos0/env
* License : Expat
  Programming Lang: Go
  Description : Go library for parse environment variables to structs

 This is a Simple Golang library to parse environment variables to structs.
 Out of the box all built-in types are supported, plus a few others that are
 commonly used. Supports the following type:
 .
  - string
  - bool
  - int
  - int8
  - int16
  - int32
  - int64
  - uint
  - uint8
  - uint16
  - uint32
  - uint64
  - float32
  - float64
  - string
  - time.Duration
  - encoding.TextUnmarshaler
  - url.URL

Re: git & Debian packaging sprint report

[Ansgar Burchardt]

Russ Allbery writes:
> Ansgar Burchardt  writes:
>> The client tool could possibly also just create the .dsc and .changes,
>> except for hashes of the compressed files, and the web service just
>> recreate the tarball and compress them.
>
> I think experience with pristine-tar indicates that recreating tarballs is
> unfortunately not trivial.

pristine-tar tries to recreate an arbitrary tarball that was created by
a third-party; in this case both sides are controlled by the same party.
Using the uncompressed tarballs also avoids possible problems from the
compression algorithm.

This is a simpler problem than what pristine-tar tries to solve.

For upstream tarballs, one can fetch them from the upstream source if
matching the upstream release is desired.

Ansgar

Re: git & Debian packaging sprint report

[Russ Allbery]

Ansgar Burchardt  writes:

> SHA-1 isn't going to get stronger in the future.  The TLS world has
> already moved on, OpenPGP is still in the slow process to move on,
> Release/Packages stopped using it[1], there is no reason to continue
> using it.

Well, the reason to continue using it is that Git uses it and we use Git,
and it may simplify the workflow.

You're not wrong, of course, but preimage attacks are very hard.  MD5 is
still probably robust against preimage attacks, let alone SHA-1.  By all
means, let's future-proof as much as possible, but I'm not sure worrying
about SHA-1 preimage resistance is the most important design principle in
this case.  At some point, Git itself will switch away from SHA-1, and we
can then obviously follow.

That said, there's enough custom logic going on here that it may be easy
to add something that you describe, in which case, great.

> The client tool could possibly also just create the .dsc and .changes,
> except for hashes of the compressed files, and the web service just
> recreate the tarball and compress them.

I think experience with pristine-tar indicates that recreating tarballs is
unfortunately not trivial.

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

Re: git & Debian packaging sprint report

[Ansgar Burchardt]

Russ Allbery writes:
> Ansgar Burchardt writes:
>> Russ Allbery writes:
>>> If so, I think that security model is roughly equivalent to the
>>> automatic signing of binary packages by buildds, so probably doesn't
>>> introduce a new vulnerability,
>
>> It doesn't rely on strong cryptographic hashes to guarantee integrity.
>> To quote Wikipedia:
>
>> +---
>> | Revision control systems such as Git, Mercurial, and Monotone use
>> | SHA-1 not for security but to identify revisions and to ensure that
>> | the data has not changed due to accidental corruption.
>> +---[ https://en.wikipedia.org/wiki/SHA-1#Data_integrity ]
>
>> But developers could instead just sign artifacts using a strong
>> cryptographic hash that will be included in the source package; for
>> example the .orig.tar and .debian.tar which can be made reproducible
>> (git-archive is supposed to be reproducible; compression might not be so
>> just sign the uncompressed version).
>
>> We shouldn't go back to trusting SHA-1.
>
> I'm dubious that we really care that much about a preimage attack on
> SHA-1, but sure, if there's some easy way to use something different, that
> would be more future-proof.

SHA-1 isn't going to get stronger in the future.  The TLS world has
already moved on, OpenPGP is still in the slow process to move on,
Release/Packages stopped using it[1], there is no reason to continue
using it.

There is another advantage to developers signing the artifacts: one
would need much less trust in the service building the source files as
it could only manipulate the .dsc, .changes and compression used.

It also has one downside: `git tag` alone won't be enough to generate
the required information, but then a special-purpose tool was proposed
here already.

The client tool could possibly also just create the .dsc and .changes,
except for hashes of the compressed files, and the web service just
recreate the tarball and compress them.  That would require near zero
trust in the web service, but still allow developers to no longer upload
source packages which might be large.  (A bit similar to not having to
trust buildds by making packages reproducible.)

Ansgar

  [1] Though we still have MD5sum for some suites for jigdo...

Bug#932141: ITP: python-sphinx-issues -- extension for linking to project's issue tracker

[Ondřej Nový]

Package: wnpp
Severity: wishlist
Owner: Ondřej Nový 

* Package name: python-sphinx-issues
  Version : 1.2.0
  Upstream Author : Steven Loria
* URL : https://github.com/sloria/sphinx-issues/
* License : Expat
  Programming Lang: Python
  Description : extension for linking to project's issue tracker

A Sphinx extension for linking to your project's issue tracker. Includes roles 
for linking to issues, pull requests, user profiles, with built-in support for 
GitHub (though this works with other services).

I'm going to maintain this inside DPMT team.

Expired InRelease files

[Daniel Reichelt]

Hi,

not sure against which package to file a bug so I'm posting here.

Since today on apt update I get:


E: Release file for
http://ftp.de.debian.org/debian-debug/dists/bullseye-debug/InRelease is
expired (invalid since 4h 32min 12s). Updates for this repository will
not be applied.
E: Release file for
http://ftp.de.debian.org/debian-debug/dists/sid-debug/InRelease is
expired (invalid since 4h 32min 13s). Updates for this repository will
not be applied.



Cheers
Daniel



signature.asc
Description: OpenPGP digital signature

Re: git & Debian packaging sprint report

[Russ Allbery]

Ansgar Burchardt  writes:
> Russ Allbery writes:

>> If so, I think that security model is roughly equivalent to the
>> automatic signing of binary packages by buildds, so probably doesn't
>> introduce a new vulnerability,

> It doesn't rely on strong cryptographic hashes to guarantee integrity.
> To quote Wikipedia:

> +---
> | Revision control systems such as Git, Mercurial, and Monotone use
> | SHA-1 not for security but to identify revisions and to ensure that
> | the data has not changed due to accidental corruption.
> +---[ https://en.wikipedia.org/wiki/SHA-1#Data_integrity ]

> But developers could instead just sign artifacts using a strong
> cryptographic hash that will be included in the source package; for
> example the .orig.tar and .debian.tar which can be made reproducible
> (git-archive is supposed to be reproducible; compression might not be so
> just sign the uncompressed version).

> We shouldn't go back to trusting SHA-1.

I'm dubious that we really care that much about a preimage attack on
SHA-1, but sure, if there's some easy way to use something different, that
would be more future-proof.

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

Re: git & Debian packaging sprint report

[Ansgar Burchardt]

Russ Allbery writes:
> If so, I think that security model is roughly equivalent to the automatic
> signing of binary packages by buildds, so probably doesn't introduce a new
> vulnerability,

It doesn't rely on strong cryptographic hashes to guarantee integrity.
To quote Wikipedia:

+---
| Revision control systems such as Git, Mercurial, and Monotone use
| SHA-1 not for security but to identify revisions and to ensure that
| the data has not changed due to accidental corruption.
+---[ https://en.wikipedia.org/wiki/SHA-1#Data_integrity ]

But developers could instead just sign artifacts using a strong
cryptographic hash that will be included in the source package; for
example the .orig.tar and .debian.tar which can be made reproducible
(git-archive is supposed to be reproducible; compression might not be so
just sign the uncompressed version).

We shouldn't go back to trusting SHA-1.

> There are also some interesting nuances here around handling DM packages,
> where not everyone with a key in the keyring can upload every package,
> although the obvious way to address that is probably for this service to
> do the same DM checks that ftpmaster would normally do.

We have other permissions checks as well; they shouldn't be
reimplemented in different places.  Instead the archive (dak) should
know who signed the package.

Ansgar

Re: hping3: git repository missing

[Holger Levsen]

On Mon, Jul 15, 2019 at 06:01:39PM +, Stefan Pietsch wrote:
> This affects more Debian packages:
> https://qa.debian.org/developer.php?email=gui%40iroqwa.org
> 
> Do you know if the maintainer is still active?

it's not a particular problem of this particular maintainer, but rather
of almost 1 source packages in Debian, see
https://trends.debian.net/#vcs-hosting and look how much alioth is
'still in use'... :/


-- 
tschau,
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: hping3: git repository missing

[Stefan Pietsch]

On 15.07.19 18:22, Geert Stappers wrote:

> Yes, that is what https://tracker.debian.org/pkg/hping3 also says.
> 
> At https://anonscm.debian.org/ is a link
> to https://alioth-archive.debian.org/
> 
> However under https://alioth-archive.debian.org/git/ is
> indeed no hping3
> 
> 
> So `apt-get source hping3` might a good starting point
> to revive  "hping3"

This affects more Debian packages:
https://qa.debian.org/developer.php?email=gui%40iroqwa.org

Do you know if the maintainer is still active?

Re: git & Debian packaging sprint report

[Sean Whitton]

Hello,

On Mon 15 Jul 2019 at 10:22AM -07, Russ Allbery wrote:

> Just to make sure I fully understand the model, is the idea that this
> system will verify the signature on the Git tag, construct a source
> package from the signed archive, and then sign the resulting source
> package with some internal key?

Assuming that by 'archive' you mean the committish at which the
DD-signed tag points, then yes, that's the model.

> If so, I think that security model is roughly equivalent to the automatic
> signing of binary packages by buildds, so probably doesn't introduce a new
> vulnerability, but my understanding was that the identity of the signature
> on the source package was used in various other places.  Presumably we
> would need to introduce some new metadata so that the uploader is mapped
> properly to the Git tag signer, rather than to some internal identity of
> the source package construction service.

Right.  This might be needed.

> Also, doesn't the archive publish the signed *.dsc files currently?  I
> believe this would mean that we would lose some published information from
> those files that we currently have (namely which DD and which key signed
> the package, which could be useful data in some incident response
> scenarios).  That said, there's been some discussion for some time about
> having the archive sign all the *.dsc files instead of keeping the
> uploader signature, which may be from an expired or unverifiable key
> (particularly for packages that haven't been uploaded in some time).

As you say, DD signatures on .dscs are only reliably useful in sid,
where they're quite likely to be verifiable.

So perhaps having them signed by this bot would be an improvement for
some usecases.

> There are also some interesting nuances here around handling DM packages,
> where not everyone with a key in the keyring can upload every package,
> although the obvious way to address that is probably for this service to
> do the same DM checks that ftpmaster would normally do.

Right.  dgit-infrastructure already has code to do that.  We just
haven't hooked it up yet.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: git & Debian packaging sprint report

[Russ Allbery]

Sean Whitton  writes:

> The current plan is for this machine to be firewalled such that it talks
> only to salsa.  For exactly the sort of reasons you describe, you won't
> be able to use this with arbitrary git hosts.

> The only untrusted input is the git tags before their signature has been
> verified against the Debian keyring.  Maybe we could isolate fetching
> and checking those tags from the part of the service which fetches the
> whole git tree to produce a source package.

Just to make sure I fully understand the model, is the idea that this
system will verify the signature on the Git tag, construct a source
package from the signed archive, and then sign the resulting source
package with some internal key?

If so, I think that security model is roughly equivalent to the automatic
signing of binary packages by buildds, so probably doesn't introduce a new
vulnerability, but my understanding was that the identity of the signature
on the source package was used in various other places.  Presumably we
would need to introduce some new metadata so that the uploader is mapped
properly to the Git tag signer, rather than to some internal identity of
the source package construction service.

Also, doesn't the archive publish the signed *.dsc files currently?  I
believe this would mean that we would lose some published information from
those files that we currently have (namely which DD and which key signed
the package, which could be useful data in some incident response
scenarios).  That said, there's been some discussion for some time about
having the archive sign all the *.dsc files instead of keeping the
uploader signature, which may be from an expired or unverifiable key
(particularly for packages that haven't been uploaded in some time).

There are also some interesting nuances here around handling DM packages,
where not everyone with a key in the keyring can upload every package,
although the obvious way to address that is probably for this service to
do the same DM checks that ftpmaster would normally do.

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

Re: git & Debian packaging sprint report

[Sean Whitton]

Hello Michael,

On Mon 15 Jul 2019 at 01:16PM +02, Michael Kesper wrote:

> Nonetheless it seems to me you are moving from trusting local signing
> to trusting upload by salsa, thereby making salsa more attractive for
> attackers.

I don't follow -- the git tag is PGP-signed, locally, by the uploader.
Just like how they would PGP-sign, locally, the .dsc and .changes.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: systemd services that are not equivalent to LSB init scripts

[Russ Allbery]

Peter Pentchev  writes:
> On Sun, Jul 14, 2019 at 12:30:16PM -0700, Russ Allbery wrote:

>> There seems to be a clear infrastructure gap for the non-systemd world
>> here that's crying out for some inetd-style program that implements the
>> equivalent of systemd socket activation and socket passing using the
>> same protocol, so that upstreams can not care whether the software is
>> started by systemd or by that inetd, and provides an easy-to-configure
>> way for Debian packages to indicate this should be used if systemd
>> isn't in play.  It doesn't seem like it would be too difficult to
>> implement such a thing, but I don't think it already exists.

> https://bugs.debian.org/922353

> https://gitlab.com/dkg/socket-activate

> In the words of Douglas Adams, "there is another theory which states
> that this has already happened" :)

Great!  So can we close the loop on the rest of the puzzle, which is how
to transparently use this facility in packaging for daemons that are
normally socket-activated with systemd on systems that don't use systemd?
That would help the sustainability of our approach here a lot, I think.

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

Re: hping3: git repository missing

[Geert Stappers]

On Mon, Jul 15, 2019 at 03:28:48PM +, Stefan Pietsch wrote:
> Dear Debian developers,
> 
> the git repository for hping3 does not exist.
> 
> apt source points to git://anonscm.debian.org/collab-maint/hping3.git
> 
> 
> $ git clone git://anonscm.debian.org/collab-maint/hping3.git
> Cloning into 'hping3'...
> fatal: unable to connect to anonscm.debian.org:
> anonscm.debian.org[0: 194.177.211.202]: errno=Connection refused
> anonscm.debian.org[1: 2001:648:2ffc:deb::211:202]: errno=Connection refused
> 

Yes, that is what https://tracker.debian.org/pkg/hping3 also says.

At https://anonscm.debian.org/ is a link
to https://alioth-archive.debian.org/

However under https://alioth-archive.debian.org/git/ is
indeed no hping3


So `apt-get source hping3` might a good starting point
to revive  "hping3"



Groeten
Geert Stappers
-- 
Leven en laten leven


signature.asc
Description: PGP signature

hping3: git repository missing

[Stefan Pietsch]

Dear Debian developers,

the git repository for hping3 does not exist.

apt source points to git://anonscm.debian.org/collab-maint/hping3.git


$ git clone git://anonscm.debian.org/collab-maint/hping3.git
Cloning into 'hping3'...
fatal: unable to connect to anonscm.debian.org:
anonscm.debian.org[0: 194.177.211.202]: errno=Connection refused
anonscm.debian.org[1: 2001:648:2ffc:deb::211:202]: errno=Connection refused



Regards,
Stefan

Re: Dropping Release and Release.gpg support from APT

[Philipp Kern]

On 2019-07-09 20:53, Julian Andres Klode wrote:

we currently have code dealing with falling back from InRelease
to Release{,.gpg} and it's all a bit much IMO. Now that buster
has been released with an InRelease file, the time has IMO come for
us to drop support for the old stuff from APT!

Timeline suggestion
---
now add a warning to apt 1.9.x for repositories w/o InRelease,
but Release{,.gpg}
Aug/Sep turn the warning into an error, overridable with an option 
(?)

Q1 2020 remove the code

My idea being that we give this a cycle in the Ubuntu 18.10 stable
release before we drop it, so people are ready for it.

Why remove it?
--
* It's annoying UX to have repositories with Release files and the 
"Ign" lines

* Handling the fallback from InRelease to Release{,.gpg} involves some
abstractions
  and logic and the less logic we have in security-relevant file
fetching, the better


One thing worth noting in case we drop support for generating the files: 
It looks like choose-mirror (no bug found) and net-retriever (bug in 
[1]) in d-i still use Release and not InRelease. Found by investigating 
annoying file races internally that would have been solved by 
InRelease...


Kind regards
Philipp Kern

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926035

Re: Propositon: Multiarchitecture Support in Next Debian 64-bit, Mozilla Firefox Release,...

[Marvin Renich]

* patrick.dre...@gmx.net  [190714 14:24]:
> Propositon: Multiarchitecture Support in Next Debian 64-bit (64-bit and
> 32-bit), Mozilla Firefox Release, in LXDE Startup Menu a Search field
> 32-bit i386 for Adobe Reader ftp.adobe.com

All of your recent posts to this list (debian-devel@lists.debian.org)
are more appropriate for the debian-user mailing list
(debian-u...@lists.debian.org).  In the future, please ask for help
there first.

Debian already has multi-architecture support, and running 64-bit
(amd64) and 32-bit (i386) programs simultaneously on a system whose
hardware supports amd64 instructions has been possible for a number of
years now.  A Google search for debian multiarch or debian
multiarchitecture will both give you the Debian Multiarch HOWTO wiki
page as the first result.

Please try to help yourself before asking others to spoon feed you
answers.

When you have suggestions, please try to determine the current status of
those features in Debian (e.g. Multiarch or Firefox vs Firefox ESR).
Asking on debian-user is a good resource for this; debian-devel is not
the right place to ask these questions.  If you determine that the
feature does not exist, familiarize yourself with the Debian Bug
Tracking System  and determine the
appropriate package (e.g. lxde or debian-installer) and file a bug on
that package with severity wishlist.  If you are having trouble
determining which package is appropriate, ask on the debian-user mailing
list.  The command reportbug, which is installed on a default Debian
installation, can help you through the process of filing a bug and
setting the appropriate severity.  All feature requests should have
severity wishlist.

Debian already has a number of PDF readers; ask on debian-user if you
cannot find one you like by searching with Google (or using synaptic or
one of the other package managers on your Debian system).

To reiterate, try to use search engines like Google or DuckDuckGo first.
If that doesn't work, ask on debian-user or some other user support
channel.  There is also a debian-user-french mailing list if that would
be easier for you.

...Marvin

Processed: kernel bug it seems

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> reassign 931290 linux-image-4.9.0-9-amd64
Bug #931290 [general] general: Asrock A300 Deskmini AMD Athlon 200GE ends in 
black screen Monitor has no Signal
Bug reassigned from package 'general' to 'linux-image-4.9.0-9-amd64'.
Ignoring request to alter found versions of bug #931290 to the same values 
previously set
Ignoring request to alter fixed versions of bug #931290 to the same values 
previously set
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
931290: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931290
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Re: systemd services that are not equivalent to LSB init scripts

[Simon Richter]

Hi,

On Mon, Jul 15, 2019 at 01:49:04PM +0200, Guillem Jover wrote:

> > In the same way, we could implement "service monitoring" in sysvinit by
> > adding an "inittab.d" directory, but I'm fairly sure that I'm not the first
> > person who had this idea in the last thirty years, so there is probably a
> > reason why it hasn't been done.

> Yeah, this is something that has slightly bothered me too, even though
> sysvinit is a bit poor at services monitoring TBH. I guess I might either
> file a request upstream, or send a patch at some point.

That's why I put it in "scare quotes". My general thoughts on this are:

 - service monitoring is itself a service that may have an arbitrarily
   complex technology stack and dependency tree
 - except for very specific circumstances, restarting a failed service is
   the wrong thing to do
- files might be in an inconsistent or invalid state
- if the service was attacked, restarting it gives more attack surface

So my guess is that there was simply no real demand for init to ever
restart daemons in a real world scenario.

I've never needed it in twenty years, at least.

   Simon

Re: systemd services that are not equivalent to LSB init scripts

[Paul Wise]

On Mon, Jul 15, 2019 at 6:48 PM Simon Richter wrote:

> The main limitation seems to be that it's not permitted to modify
> inetd.conf from maintainer scripts. We could probably "fix" this by adding
> an "inetd.conf.d" mechanism.

There is update-inetd, but it doesn't support xinetd and doesn't
appear to have debhelper integration.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: systemd services that are not equivalent to LSB init scripts

[Guillem Jover]

On Mon, 2019-07-15 at 12:30:09 +0200, Simon Richter wrote:
> On Sun, Jul 14, 2019 at 07:23:31PM +0100, Simon McVittie wrote:
> > Some systemd system services are meant to start on-demand via socket
> > events (systemd.socket(5)), and can work via inetd on non-systemd-booted
> > systems. micro-httpd appears to be an example of this - I'm a bit surprised
> > there aren't more. Perhaps this indicates limitations in the infrastructure
> > around inetd services making it hard to implement "use systemd.socket(5)
> > under systemd or inetd otherwise"?
> 
> The main limitation seems to be that it's not permitted to modify
> inetd.conf from maintainer scripts. We could probably "fix" this by adding
> an "inetd.conf.d" mechanism.

Oh, but inetutils-inetd does support /etc/inetd.d/ (since 2000). The
problem is that this would need to be implemented by all inetd daemons
in Debian.

And I'd like to move forward at some point with a switch to declarative
update-inetd handling, which would cover some of this.

I also added the equivalent for inetutils-syslogd with /etc/syslog.d/
(since 2008).

> In the same way, we could implement "service monitoring" in sysvinit by
> adding an "inittab.d" directory, but I'm fairly sure that I'm not the first
> person who had this idea in the last thirty years, so there is probably a
> reason why it hasn't been done.

Yeah, this is something that has slightly bothered me too, even though
sysvinit is a bit poor at services monitoring TBH. I guess I might either
file a request upstream, or send a patch at some point.

Thanks,
Guillem

Re: systemd services that are not equivalent to LSB init scripts

[Peter Pentchev]

On Sun, Jul 14, 2019 at 12:30:16PM -0700, Russ Allbery wrote:
> Vincent Bernat  writes:
> 
> > inetd uses stdin/stdout to communicate with the daemon and have to
> > launch one instance for each client connecting. systemd.socket pass a
> > regular listening socket on first connection to the daemon and the
> > daemon can then serve multiple clients.
> 
> I believe the wait option for at least xinetd behaves in roughly the same
> way, although it's normally only used for UDP services.
> 
> There seems to be a clear infrastructure gap for the non-systemd world
> here that's crying out for some inetd-style program that implements the
> equivalent of systemd socket activation and socket passing using the same
> protocol, so that upstreams can not care whether the software is started
> by systemd or by that inetd, and provides an easy-to-configure way for
> Debian packages to indicate this should be used if systemd isn't in play.
> It doesn't seem like it would be too difficult to implement such a thing,
> but I don't think it already exists.

https://bugs.debian.org/922353

https://gitlab.com/dkg/socket-activate

In the words of Douglas Adams, "there is another theory which states
that this has already happened" :)

> I believe the convention in the runit/daemontools world is to decide this
> is not an important problem to solve and lots of small running daemons is
> not something that needs to be avoided, and to use tcpserver or some
> equivalent that behaves like inetd for a single service.  Even here,
> though, I'm not sure if any of those implementations use the same socket
> passing protocol as systemd, and I'm not sure if they're yet trivial to
> configure as part of Debian packaging.

tcpserver certainly does not, it implements the UCSPI protocol, which is
a good one in itself, but it is still a different one.

G'luck,
Peter

-- 
Peter Pentchev  roam@{ringlet.net,debian.org,FreeBSD.org} p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13


signature.asc
Description: PGP signature

Re: git & Debian packaging sprint report

[Michael Kesper]

Hi Sean, hi all,

On 12.07.19 09:00, Sean Whitton wrote:
> On Fri 12 Jul 2019 at 04:30am +00, Scott Kitterman wrote:
> 
>> Has there been any analysis of the security implications of this
>> proposed service?
> 
> Nothing formal, though of course we were thinking about it while we were
> working on it.
> 
>> If I am understanding the description correctly, the transformation
>> from git tag (which is signed and can be verified) to a source package
>> (which can be signed and verified) will happen on an internet facing
>> server (typically this would happen on a local developer machine) and,
>> unless there is additional magic around key management that isn't
>> described in the blog post, the private key for a key the archive
>> trusts would also be there.
>>
>> It seems to me that there is potential for a significant new attack
>> surface that ought to be carefully assessed before this gets anywhere
>> near wired up to feed into the archive from any kind of 'cloud'
>> service.
> 
> The current plan is for this machine to be firewalled such that it talks
> only to salsa.  For exactly the sort of reasons you describe, you won't
> be able to use this with arbitrary git hosts.
> 
> The only untrusted input is the git tags before their signature has been
> verified against the Debian keyring.  Maybe we could isolate fetching
> and checking those tags from the part of the service which fetches the
> whole git tree to produce a source package.

Nonetheless it seems to me you are moving from trusting local signing
to trusting upload by salsa, thereby making salsa more attractive for 
attackers.

Best wishes
Michael
 




signature.asc
Description: OpenPGP digital signature

Re: systemd services that are not equivalent to LSB init scripts

[Simon Richter]

Hi,

On Sun, Jul 14, 2019 at 07:23:31PM +0100, Simon McVittie wrote:

> Some systemd system services are meant to start on-demand via socket
> events (systemd.socket(5)), and can work via inetd on non-systemd-booted
> systems. micro-httpd appears to be an example of this - I'm a bit surprised
> there aren't more. Perhaps this indicates limitations in the infrastructure
> around inetd services making it hard to implement "use systemd.socket(5)
> under systemd or inetd otherwise"?

The main limitation seems to be that it's not permitted to modify
inetd.conf from maintainer scripts. We could probably "fix" this by adding
an "inetd.conf.d" mechanism.

In the same way, we could implement "service monitoring" in sysvinit by
adding an "inittab.d" directory, but I'm fairly sure that I'm not the first
person who had this idea in the last thirty years, so there is probably a
reason why it hasn't been done.

   Simon

trends.debian.net updated

[Lucas Nussbaum]

Hi,

I updated https://trends.debian.net .

Main changes:
* Refreshed data (up to July 2019)
* Added data about DEP5 copyright format adoption
* Added data about autopkgtest adoption
* Various minor changes

Now is probably a good time to go through smells in your packages and
update them to newer standards. As a reminder, there's a dd-list at
https://trends.debian.net/smells-dd-list.txt :-)

As another reminder, the dh discussion summary[1] includes the following
points which could be useful in that case as well:

> Best Practices for Testing DH Conversions
> =
> 
> * Run a debdiff of the binaries to see what has changed
> 
> * Use diffoscope
> 
> * Run autopkgtests
> 
> * Test piuparts
> 
> Generally look at the packaging and explain any changes carefully.

Lucas


[1] https://lists.debian.org/debian-devel-announce/2019/06/msg4.html