Re: Limited security support for Go/Rust? Re ssh3

[Bastian Blank]

On Wed, Jan 24, 2024 at 11:40:20PM +, Wookey wrote:
> If it only done for security issues, rather than routinely, then that
> shouldn't be that much extra load (does anyone have any idea how much
> extra building we are talking about? Is it trivial, or huge?)

If we do those rebuilds in stable security we have several bottlenecks:

- We need to get all the other packages into security, need some way to
  trigger rebuilds (I still think we need to kill the current way of
  BinNMU alltogether)
- Those can only build after the fixed package was released (or at least
  completely built)
- DSA are supposed to be available for all updates, so we now need to
  list hundred of packages.
- The separate security archive is severely space limited.
- SRM like to look at all updates as well.

Bastian

-- 
Worlds are conquered, galaxies destroyed -- but a woman is always a woman.
-- Kirk, "The Conscience of the King", stardate 2818.9

Re: icc-profiles_2.2_source.changes REJECTED

[Jonas Smedegaard]

Quoting Jeremy Bícha (2024-01-25 02:50:07)
> On Fri, Mar 3, 2023 at 5:58 PM Bastien Roucariès  wrote:
> > Le vendredi 3 mars 2023, 22:35:24 UTC Jonas Smedegaard a écrit :
> > > Quoting Bastien Roucariès (2023-03-03 22:21:49)
> > > > Le lundi 27 février 2023, 12:11:27 UTC Jonas Smedegaard a écrit :
> > > > Hi jonas,
> > > >
> > > > I have just checked the source code of lintian. Could you double check 
> > > > your package and create a simple test case ?
> > > >
> > > > According to:
> > > > https://salsa.debian.org/lintian/lintian/-/blob/master/lib/Lintian/Check/Files/NonFree.pm#L91
> > > > The test should not raise
> > >
> > > Sorry, I don't understand what you ask me to do.
> > >
> > > In case it was unclear from my previous posts: The rejection messages I
> > > shared was not from a lintian check done locally by me, but a rejection
> > > message I received from ftpmaster.
> > >
> > > Locally I did not experience the same messages.  Are you asking me to
> > > test again that I (again) do not experience the kind of messages that
> > > ftpmasters for some reason unknown to me trigger?
> >
> > Yes could you double check ?
> >
> > If you do not experience the kind of messages with locally installed 
> > lintian, it means that lintian need to be backported and that ftpmaster 
> > should install a backport version.
> 
> I am still getting the LIntian autoreject for thawab for
> license-problem-md5sum-non-free. It is especially annoying that
> current Lintian does not emit this error or even a warning because it
> knows that thawab is in non-free.
> 
> This is blocking me from being able to fix a RC bug in thawab unless I
> repack the tarball which seems like a lot of work for a package that
> is in non-free and a version that is **already in the archives**.
> 
> I originally tried to fix this RC bug a year ago but my upload
> was auto-rejected then and I forgot to mark this issue for followup.
> It was an early enough upload that thawab could have landed in Debian
> 12.
> 
> https://alioth-lists.debian.net/pipermail/debian-islamic-maintainers/2023-January/004920.html

For the record I have not heard from ftpmasters on this issues, and I
know only what is in this public mailinglist thread.

Obviously I would be happy to be able to maintain the package that I am
listed as maintainer of.  And if that for some reason is unreasonable of
me to expect then I would appreciate an explanation why.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

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

signature.asc
Description: signature

Re: icc-profiles_2.2_source.changes REJECTED

[Jeremy Bícha]

On Fri, Mar 3, 2023 at 5:58 PM Bastien Roucariès  wrote:
> Le vendredi 3 mars 2023, 22:35:24 UTC Jonas Smedegaard a écrit :
> > Quoting Bastien Roucariès (2023-03-03 22:21:49)
> > > Le lundi 27 février 2023, 12:11:27 UTC Jonas Smedegaard a écrit :
> > > Hi jonas,
> > >
> > > I have just checked the source code of lintian. Could you double check 
> > > your package and create a simple test case ?
> > >
> > > According to:
> > > https://salsa.debian.org/lintian/lintian/-/blob/master/lib/Lintian/Check/Files/NonFree.pm#L91
> > > The test should not raise
> >
> > Sorry, I don't understand what you ask me to do.
> >
> > In case it was unclear from my previous posts: The rejection messages I
> > shared was not from a lintian check done locally by me, but a rejection
> > message I received from ftpmaster.
> >
> > Locally I did not experience the same messages.  Are you asking me to
> > test again that I (again) do not experience the kind of messages that
> > ftpmasters for some reason unknown to me trigger?
>
> Yes could you double check ?
>
> If you do not experience the kind of messages with locally installed lintian, 
> it means that lintian need to be backported and that ftpmaster should install 
> a backport version.

I am still getting the LIntian autoreject for thawab for
license-problem-md5sum-non-free. It is especially annoying that
current Lintian does not emit this error or even a warning because it
knows that thawab is in non-free.

This is blocking me from being able to fix a RC bug in thawab unless I
repack the tarball which seems like a lot of work for a package that
is in non-free and a version that is **already in the archives**.

I originally tried to fix this RC bug a year ago but my upload
was auto-rejected then and I forgot to mark this issue for followup.
It was an early enough upload that thawab could have landed in Debian
12.

https://alioth-lists.debian.net/pipermail/debian-islamic-maintainers/2023-January/004920.html

Thank you,
Jeremy Bícha

Re: Proposal for how to deal with Go/Rust/etc security bugs

[Wookey]

On 2024-01-24 13:29 +0100, Simon Josefsson wrote:
> Luca Boccassi  writes:
> 
> > There's always option B: recognize that the Rust/Go ecosystems are not
> > designed to be compatible with the Linux distributions model

Luca is quite right here. Ultimately this can only be fixed by these
ecosystems understanding that software in these languages cannot be
sensibly used in distributions until they support modularity and
stability. The rust people make the excuse that they are 'too new' to
define a stable ABI. That was fair enough for a while, but it's
getting to be quite a thin excuse at this point. I think the real
issue now is that the people doing the work like their 'very
convenient for developers, who cares about anyone else' model so
no-one in that community is very bothered to fix it. People like us
probably need to put in time to help them.

> Go seems to have supported shared libraries since around ca 2015:
> 
> https://go.dev/talks/2015/state-of-go-may.slide#13
> https://docs.google.com/document/d/1nr-TQHw_er6GOQRsF6T43GGhFDelrAP0NqSS_00RgZQ/edit

OK. So at least they _have_ a shared library mechanism we could
use. Does anyone know what is stopping debian from using it? Can we
just start requiring go stuff to build shared libraries in policy?
I've done this before with C libraries where upstream only ever
shipped a static library so the makefiles had to be expanded a bit,
but it's not a lot of work. Is that all we need in Go, or is there
some larger issue or much more work needed?

> > There are many ways to ship applications today that are much better
> > suited for these models, like Flatpak, where the maintenance burden is
> > shifted onto those who choose to opt in to such ecosystems.

Simply ignoring them until they get a clue would be nice, but I don't
think it's very practical at this point, and would be a disservice to
our users.

But I am certainly in favour of directing effort to try to get
relevant change upstream in the ecosystems. i.e stop chopping long
enough to sharpen our axe. I have done some of this in the Rust
ecosystem, and I know there is quite a lot of corporate pressure being
applied. People keep telling us (@ARM) how marvellous Rust is, and we keep
telling them that it's useless in the real world until it sorts out
the stable ABI/dynamic linking problem.

I guess it might be time for another go to see if we can get some traction.

Wookey
-- 
Principal hats:  Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: PGP signature

Re: Limited security support for Go/Rust? Re ssh3

[Wookey]

On 2024-01-16 10:59 +0100, Simon Josefsson wrote:

> My naive approach on how to fix a security problem in package X which is
> statically embedded into other packages A, B, C, ... would be to rebuild
> the transitive closure of all packages that Build-Depends on X and
> publish a security update for all those packages.
> 
> What is the problem with that approach to handle security problems in a
> Go package for trixie?

Well, the reason we have not done this in the past is that the rebuild
propogation needed potentially adds significant load to the buildds,
and we used to have barely enough capacity to keep up with uploads for
some architectures. I think that situation is quite a lot better these
days, at least for release architectures, but I'm not sure how much
slack there is in the system across the board? Other distros that
routinely rebuild everything don't support anything like as many
architectures.

If it only done for security issues, rather than routinely, then that
shouldn't be that much extra load (does anyone have any idea how much
extra building we are talking about? Is it trivial, or huge?)

Wookey
-- 
Principal hats:  Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: PGP signature

Re: Proposal for how to deal with Go/Rust/etc security bugs (was: Re: Limited security support for Go/Rust? Re ssh3)

[Marco d'Itri]

On Jan 24, Peter Pentchev  wrote:

> This might be a minority, optimistic, rose-tinted-glasses kind of
> opinion, but I believe that the state of the Rust ecosystem today
> (I have no experience with the Go one) is quite similar to what Perl and
> Python modules were 25, 20, bah, even 15 years ago. Gradually, with time,
I am not familiar with the Python ecosystem, but I have been writing 
Perl and packaging software with Perl dependencies for over 25 years and 
I can confidently say that this is not true.
Perl libraries ("modules") generally never had the API instability that 
I have seen in Rust libraries (but much less in Go, I believe).
In my experience forward compatibility has always been very important in 
the Perl ecosystem.

BTW, for the past couple of years I have been presenting to my other 
community, the network operators, about some of my Debian work and these 
problems with integrating complex Rust software in distributions, e.g.
https://www.linux.it/~md/text/rpki-validators-euroix2023.pdf .

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: build profile proposal: nogir (second try)

[Helmut Grohne]

On Wed, Jan 24, 2024 at 06:30:02PM +, Alberto Garcia wrote:
> - Are packages that ship gobject-introspection files supposed to have
>in the relevant build dependencies (gir1.2-*-dev,
>   gobject-introspection ?), or is the build profile handling this
>   automatically?

This is not automatic. Please annotate relevant Build-Depends manually.

> - Packages using dh_install may have a line with usr/share/gir-1.0 in
>   their debian/libfoo-dev.install. This will fail if the .gir files
>   are not generated. What's the recommended way to handle this?

There is no silver bullet. Options:

 * You may use dh-exec. When doing so, you may annotate lines with build
   profiles. For example, samba's debian/winbind.install uses this
   approach.

 * You may conditionally run dh_install from debian/rules passing
   affected files as arguments.

 * You may split the affected files into a separate binary package to
   avoid this annoyance.

Helmut

static linking, modularity, and community (was: Proposal for how to deal with Go/Rust/etc security bugs)

[G. Branden Robinson]

[follow-ups should probably go to -project, but I'm not setting my
headers to try to force that]

At 2024-01-24T16:57:06+0100, Simon Josefsson wrote:
> One could equally well make the argument that distributors should care
> about the Go/Rust ecosystems, and make whatever changes needed in
> order to support them.  Those changes are what I'm trying to explore
> here.

Exploration is one thing; advocacy is another.  Please be clear which
role you're taking in any given discussion.  (If you switch hats
midstream, be explicit about it).

[rearranging]
> Speaking as a C person (I know little about Go/Rust), getting stable
> ABIs, dynamic linking [...] right is not simple, and we've been
> working on that for 20+ years consuming plenty of human resources on
> the way.

That's true, but think about the goal that stable ABIs and dynamic
shared objects achieve: software modularity in the field at runtime.  I
trust that I don't have to argue the benefits of modular design to any
even slightly experienced software developer; its benefits have been
understood for about fifty years.

(Just to get this on the record, and for obligatory technical content:
I've studied Go a little and Rust a bit more.  I think that, _as
languages_, they're likely both superior to C in most respects.  [If you
want to visualize PDP-11 assembler output and stack layout as you code,
both are likely ill-suited to the purpose, as standard C itself
increasingly is.]  In any case they are well worth a software
professional's time to look at, in my opinion.  That doesn't mean you
have to endorse their adoption.)

> and security upgrades

And there's the payoff of dynamic modularity, if you will.

If the origin of a statically linked object, whatever its language of
implementation, is not on the ball _for any reason_, the exposure of a
security vulnerability in it or anything upon which it depends expands a
temporal window of attack on affected systems.  We _know_ that certain
actors in the global IT sector hoard undisclosed vulnerabilities for
deployment later, at opportune times for extortion or data exfiltration
against targets of interest.

Next, consider some of the reasons why the origin of a statically linked
object might come "off the ball".  Maybe they got fired or laid off.
Maybe they burned out.  Maybe they died.  Maybe they've been told the
project is supposed to become part of their "20% time"[sic].  Maybe it's
just "not a priority" to their employer.  Maybe they had a baby or
finally went on that long-planned vacation to a tropical island.

If you've worked in Big IT you know that you can predict that when your
business unit gets a new director, _you_ get a new direction.  Directors
and other senior managers justify their huge salaries and benefit
packages by being "impactful", and one reliable way to be "impactful" is
by handing down dramatic decrees.  (All of the top capitalists are
gamblers; one can easily perceive this in their personalities and
rhetoric.)  At one place I worked such a thing happened twice in less
than a year, I think.  We were going to "drop all Linux" and rebase
everything on FreeBSD.  Then that director departed the company and
FreeBSD was out the window--back to Linux.[1]

Worse, when any of these disruptions happens to the origin of a module
that employs static linking, it can take an indefinite amount of time to
_find out_ that such has even taken place.  So its user community may
lose time while it politely waits for their upstream to check in from
vacation or whatever, because they don't want to be rude, or seen as
hijacking the project, or similar.  And even that assumes that the right
people in the community have sufficient expertise to reasonably
approximate the usual construction and release procedures, which can
vary not just in the technology of the implementation system, but in the
hosting/development site.

Consider the motivations and pressures that professionalized, corporate
software is developed under.  Any cost of development that can be
externalized experiences an unrelenting force in that direction.

  An economic profit is the difference between the revenue received from
  sales and the explicit costs of producing its goods and services, as
  well as any opportunity costs.[2]

Opportunity costs are an interesting subject.[3]  They are often
difficult or even impossible to measure.  In business culture, they are
often therefore utterly neglected, even when they are known to exist.
This is why firms pollute, know they pollute, deny to the public that
they pollute, argue with everyone who challenges them about the
consequences of their pollution, and ultimately attempt to escape
liability for their subjection of others--ultimately, human beings and
the environment generally--to their negative externalities.  The
emphasis on profit and a desire by the wealthiest in society to preserve
the prevailing economic system is also why very concept of negative
externalities is under-emphasized or omitt

Re: Proposal for how to deal with Go/Rust/etc security bugs (was: Re: Limited security support for Go/Rust? Re ssh3)

[Peter Pentchev]

On Wed, Jan 24, 2024 at 01:01:34PM +, Luca Boccassi wrote:
> On Wed, 24 Jan 2024 at 12:26, Johannes Schauer Marin Rodrigues
>  wrote:
> >
> > Hi,
> >
> > Quoting Luca Boccassi (2024-01-24 12:59:38)
> > > There's always option B: recognize that the Rust/Go ecosystems are not
> > > designed to be compatible with the Linux distributions model, and are 
> > > instead
> > > designed to be as convenient as possible for a _single_ application 
> > > developer
> > > and its users - at the detriment of everybody else - and for large
> > > corporations that ship a handful of applications with swathes of engineers
> > > that can manage the churn, and it is not made nor intended to scale to 
> > > ~60k
> > > packages or whatever number we have today in unstable. And simply stop
> > > attempting to merge these two incompatible ecosystems against their will, 
> > > at
> > > the very least until and unless they reach feature and stability parity 
> > > with
> > > the C/C++ ecosystems - stable API/ABI and dynamic linking by default.
> > >
> > > There are many ways to ship applications today that are much better
> > > suited for these models, like Flatpak, where the maintenance burden is
> > > shifted onto those who choose to opt in to such ecosystems.
> >
> > how does that work for those applications that require rust, go and friends?
> > Are you proposing that everything that needs them should be be distributed 
> > by a
> > flatpak or similar mechanism instead?
> 
> Those applications are not shipped in the distribution. If somebody
> wants to use them, they'll have to figure it out, just like for
> everything else that is not shipped in the distribution, which is
> already a subset of all available software in the world.
> 
> > Just a few days ago I tried building mesa from experimental (otherwise there
> > are severe graphics glitches on my platform) on bookworm and everything 
> > worked
> > except its rust build dependencies.  I had no luck trying to backport those
> > parts of rust that I needed and even if it had worked, it would've meant
> > backporting dozens of rust packages just to have a backport of mesa. It 
> > seemed
> > way simpler to just disable the mesa component that requires rust and call 
> > it a
> > day. But that probably doesn't work for all applications and maybe sometimes
> > the component written in rust is actually what you want. And in case of 
> > mesa, a
> > flatpak of it probably would also not've helped as that would've meant that 
> > I
> > need to run everything that I want to run with a more modern mesa based on 
> > that
> > flatpak, right?
> >
> > So how is option B a solution in practice?
> 
> You have found first-hand the exact problem with this ecosystem. Now
> try to imagine doing that for 30k packages, all vendoring, pinning and
> static linking against each other at different, incompatible versions.
> Again, the solution in practice is to simply disable or patch out
> those components, and if somebody needs them, they can complain to
> upstream and ask them for a solution, if there is one. If there isn't,
> though luck. And yes, that is not great - but neither are all other
> options, so it seems much wiser to me to push responsibility where it
> belongs - with the upstreams choosing to use such ecosystems, and the
> owner of said ecosystems choosing to make them incompatible with the
> distribution model, as they are in the best position to solve the
> problem(s) that happen due to their design choices.

This might be a minority, optimistic, rose-tinted-glasses kind of
opinion, but I believe that the state of the Rust ecosystem today
(I have no experience with the Go one) is quite similar to what Perl and
Python modules were 25, 20, bah, even 15 years ago. Gradually, with time,
the module authors realized that if they wanted people to use their
modules, they would eventually have to settle on a stable API and
only make incompatible changes very rarely. With time, with this
realization trickling up and down across the most used libraries,
things slowly start to get better.

Yes, even now there are what can only be called "transitions" in
the Perl and Python Debian packaging - some often-used module
makes an incompatible change and the packagers need to wait until
all the other packaged modules have either caught up or it has somehow
been proven through testing that some of the dependent modules are
not really affected by the incompatible change. In my experience,
nowadays this happens much, much more rarely than 10 or 15 years ago.

I have no idea how long it will take the Rust ecosystem to realize
that. I know that some of the most widely used modules have already
done that, some of them have been at the same 0.x.* or even 1.*
version for years (yes, really, years). So... here's hoping.

G'luck,
Peter

-- 
Peter Pentchev  r...@ringlet.net r...@debian.org p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115

Re: build profile proposal: nogir (second try)

[Simon McVittie]

As Johannes mentioned earlier in this thread, the first piece of practical
advice on nogir should be: if you don't know that you need to use it,
then perhaps you shouldn't. It's primarily aimed at breaking cycles,
and enabling buildability in lower-level packages during bootstrapping.

(Having said that, at some point I want to convert some not-too-essential
library to this setup, just as a demonstration of how it works in
practice.)

file:///usr/share/doc/gobject-introspection/README.Debian.gz in recent
versions of gobject-introspection has some practical checklists for
making packages with GIR XML and typelibs cross-buildable, and for making
it possible to add the nogir profile. I would say that if you only do
one of those two things to a library, it should be making the library
cross-buildable: that's something that most libraries can benefit from.

On Wed, 24 Jan 2024 at 18:30:02 +, Alberto Garcia wrote:
> - Are packages that ship gobject-introspection files supposed to have
>in the relevant build dependencies (gir1.2-*-dev,
>   gobject-introspection ?), or is the build profile handling this
>   automatically?

If you want to skip a particular build-dependency under this build
profile, you must annotate it with . There is no other way to
skip build-dependencies, and this is true for all build profiles, not
just this one.

The goal of this build profile is more like the other way around,
really. Don't think of it as "packages that ship gobject-introspection
files should implement nogir". Think of it as more like: "packages
that build-depend on gobject-introspection stuff *might* want it to be
possible to turn off that build-dependency: and if they do, the way to
do it without causing FTBFS or breaking dependent packages is to
implement nogir".

For GIR XML and typelibs, I expect that the dependencies that will usually
be marked in this way are gir1.2-*-dev, gobject-introspection, and
libgirepository1.0-dev.

Note that if your package uses gi-docgen to generate documentation,
then that cannot work without enabling introspection, so it might need
something more like:

Build-Depends:
 ...,
 gir1.2-glib-2.0-dev  ,
 gobject-introspection  ,
 ...,

or even

Build-Depends-Arch:
 ...,
 gir1.2-glib-2.0-dev ,
 gobject-introspection ,
 ...,
Build-Depends-Indep:
 ...,
 gi-docgen ,
 gir1.2-glib-2.0-dev ,
 gobject-introspection ,
 ...,

> - Packages using dh_install may have a line with usr/share/gir-1.0 in
>   their debian/libfoo-dev.install. This will fail if the .gir files
>   are not generated. What's the recommended way to handle this?

If your GIR XML has been split into a separate gir1.2-foo-0-dev binary
package (see other discussions in this thread), then this isn't a concern
because you can turn off that entire binary package with
Build-Profiles: .

Or, if you're using this build profile in the mode where it changes the
contents of the libfoo-dev binary package (which is non-ideal, but avoids
needing to go through NEW), then there isn't really a recommended way,
but dh-exec is probably the least-bad way.

smcv

Re: build profile proposal: nogir (second try)

[Alberto Garcia]

On Wed, Jan 17, 2024 at 10:00:35PM +, Simon McVittie wrote:
> Here is the draft text that I added to the GObject-Introspection
> mini-policy in 1.78.1-11:

Hi, thanks for the explanation.

A couple of questions about this:

- Are packages that ship gobject-introspection files supposed to have
   in the relevant build dependencies (gir1.2-*-dev,
  gobject-introspection ?), or is the build profile handling this
  automatically?

- Packages using dh_install may have a line with usr/share/gir-1.0 in
  their debian/libfoo-dev.install. This will fail if the .gir files
  are not generated. What's the recommended way to handle this?

Regards,

Berto

Bug#1061446: ITP: cosign -- Code signing and transparency for containers and binaries

[Simon Josefsson]

Package: wnpp
Severity: wishlist
Owner: Simon Josefsson 

* Package name: cosign
  Version : 2.2.2-1
  Upstream Author : The Sigstore Authors
* URL : https://github.com/sigstore/cosign
* License : Apache-2.0
  Programming Lang: Go
  Description : Code signing and transparency for containers and binaries

 Signing OCI containers (and other artifacts) using Sigstore
 (https://sigstore.dev/)!
 .
 Go Report Card
 (https://goreportcard.com/report/github.com/sigstore/cosign) e2e-tests
 (https://github.com/sigstore/cosign/actions/workflows/e2e-tests.yml) CII
 Best Practices
 (https://bestpractices.coreinfrastructure.org/projects/5715) OpenSSF
 Scorecard
 (https://api.securityscorecards.dev/projects/github.com/sigstore/cosign)
 .
 Cosign aims to make signatures **invisible infrastructure**.
 .
 Cosign supports:
 .
  * "Keyless signing" with the Sigstore public good Fulcio certificate
authority and Rekor transparency log (default)
  * Hardware and KMS signing
  * Signing with a cosign generated encrypted private/public keypair
  * Container Signing, Verification and Storage in an OCI registry.
  * Bring-your-own PKI
 .
 Info
 .
 Cosign is developed as part of the sigstore (https://sigstore.dev)
 project. We also use a slack channel (https://sigstore.slack.com)! Click
 here (https://join.slack.com/t/sigstore/shared_invite/zt-mhs55zh0-
 XmY3bcfWn4XEyMqUUutbUQ) for the invite link.
 .
 Installation
 .
 For Homebrew, Arch, Nix, GitHub Action, and Kubernetes installs see the
 installation docs
 (https://docs.sigstore.dev/system_config/installation/).
 .
 For Linux and macOS binaries see the GitHub release assets
 (https://github.com/sigstore/cosign/releases/latest).
 .
 :rotating_light: If you are downloading releases of cosign from our GCS
 bucket - please see more information on the July 31, 2023 deprecation
 notice (https://blog.sigstore.dev/cosign-releases-bucket-deprecation/)
 :rotating_light:
 .
 Developer Installation
 .
 If you have Go 1.19+, you can setup a development environment:
 .
   $ git clone https://github.com/sigstore/cosign
   $ cd cosign
   $ go install ./cmd/cosign
   $ $(go env GOPATH)/bin/cosign
 .
 Contributing
 .
 If you are interested in contributing to cosign, please read the
 contributing documentation (/CONTRIBUTING.md).
 .
 Dockerfile
 .
 Here is how to install and use cosign inside a Dockerfile through the
 gcr.io/projectsigstore/cosign image:
 .
   FROM gcr.io/projectsigstore/cosign:v1.13.0 as cosign-bin
 .
   # Source: https://github.com/chainguard-images/static
   FROM cgr.dev/chainguard/static:latest
   COPY --from=cosign-bin /ko-app/cosign /usr/local/bin/cosign
   ENTRYPOINT [ "cosign" ]
 .
 Quick Start
 .
 This shows how to:
 .
  * sign a container image with the default "keyless signing" method (see
KEYLESS.md (/KEYLESS.md))
  * verify the container image
 .
 Sign a container and store the signature in the registry
 .
 Note that you should always sign images based on their digest
 (@sha256:...) rather than a tag (:latest) because otherwise you might
 sign something you didn't intend to!
 .
cosign sign $IMAGE
 .
   Generating ephemeral keys...
   Retrieving signed certificate...
 .
Note that there may be personally identifiable information associated
 with this signed artifact.
This may include the email address associated with the account with
 which you authenticate.
This information will be used for signing this artifact and will be
 stored in public transparency logs and cannot be removed later.
 .
   By typing 'y', you attest that you grant (or have permission to grant)
 and agree to have this information stored permanently in transparency
 logs.
   Are you sure you would like to continue? [y/N] y
   Your browser will now be opened to:
 .
 
https://oauth2.sigstore.dev/auth/auth?access_type=online&client_id=sigstore&code_challenge=OrXitVKUZm2lEWHVt1oQWR4HZvn0rSlKhLcltglYxCY&code_challenge_method=S256&nonce=2KvOWeTFxYfxyzHtssvlIXmY6Jk&redirect_uri=http%3A%2F%2Flocalhost%3A57102%2Fauth%2Fcallback&response_type=code&scope=openid+email&state=2KvOWfbQJ1caqScgjwibzK2qJmb
   Successfully verified SCT...
   tlog entry created with index: 12086900
   Pushing signature to: $IMAGE
 .
 Cosign will prompt you to authenticate via OIDC, where you'll sign in
 with your email address. Under the hood, cosign will request a code
 signing certificate from the Fulcio certificate authority. The subject
 of the certificate will match the email address you logged in with.
 Cosign will then store the signature and certificate in the Rekor
 transparency log, and upload the signature to the OCI registry alongside
 the image you're signing.
 .
 Verify a container
 .
 To verify the image, you'll need to pass in the expected certificate
 issuer and certificate subject via the --certificate-identity and --
 certificate-oidc-issuer flags:
 .
   cosign verify $IMAGE --certificate-identity=$IDENTITY --certificate-oidc-
 issuer=$OIDC_ISSUER
 .

Re: Proposal for how to deal with Go/Rust/etc security bugs

[Simon Josefsson]

Luca Boccassi  writes:

> On Wed, 24 Jan 2024 at 13:34, Simon Josefsson  wrote:
>>
>> Luca Boccassi  writes:
>>
>> >> Having reflected a bit, and learned through my own experience and
>> >> others' insights [1] that Go Build-Depends are not transitive, I'd like
>> >> to update my proposal on how to handle a security bug in any Go/Rust/etc
>> >> package and the resulting package rebuilds:
>> >
>> > There's always option B: recognize that the Rust/Go ecosystems are not
>> > designed to be compatible with the Linux distributions model
>>
>> Definitely - that's roughly the model we have today, right?  So no
>> action needed to preserve status quo of option B.
>>
>> I want to explore if there is a possibility to change status quo, and
>> what would be required to do so.
>
> What's required is talking to the language ecosystem owners and
> convince them to support a stable ABI and dynamic linking, and in
> general to care about the distribution use case. Otherwise it's just
> an unwinnable uphill battle that consumes a ton of scarce resources
> (developers time), and is simply hopeless.

One could equally well make the argument that distributors should care
about the Go/Rust ecosystems, and make whatever changes needed in order
to support them.  Those changes are what I'm trying to explore here.

Speaking as a C person (I know little about Go/Rust), getting stable
ABIs, dynamic linking and security upgrades right is not simple, and
we've been working on that for 20+ years consuming plenty of human
resources on the way.

/Simon


signature.asc
Description: PGP signature

Re: Proposal for how to deal with Go/Rust/etc security bugs

[Luca Boccassi]

On Wed, 24 Jan 2024 at 13:34, Simon Josefsson  wrote:
>
> Luca Boccassi  writes:
>
> >> Having reflected a bit, and learned through my own experience and
> >> others' insights [1] that Go Build-Depends are not transitive, I'd like
> >> to update my proposal on how to handle a security bug in any Go/Rust/etc
> >> package and the resulting package rebuilds:
> >
> > There's always option B: recognize that the Rust/Go ecosystems are not
> > designed to be compatible with the Linux distributions model
>
> Definitely - that's roughly the model we have today, right?  So no
> action needed to preserve status quo of option B.
>
> I want to explore if there is a possibility to change status quo, and
> what would be required to do so.

What's required is talking to the language ecosystem owners and
convince them to support a stable ABI and dynamic linking, and in
general to care about the distribution use case. Otherwise it's just
an unwinnable uphill battle that consumes a ton of scarce resources
(developers time), and is simply hopeless.

> Given how often gnulib is vendored for C code in Debian, and other
> similar examples, I don't think of this problem as purely a Go/Rust
> problem.  The parallel argument that we should not support coreutils,
> sed, tar, gzip etc because they included vendored copies of gnulib code
> is not reasonable.

As it was already explained, this is a misleading example that has
nothing to do with the problems of the Go/Rust ecosystem.

Re: Proposal for how to deal with Go/Rust/etc security bugs (was: Re: Limited security support for Go/Rust? Re ssh3)

[Jeremy Stanley]

On 2024-01-24 13:26:49 +0100 (+0100), Johannes Schauer Marin Rodrigues wrote:
[...]
> how does that work for those applications that require rust, go
> and friends? Are you proposing that everything that needs them
> should be be distributed by a flatpak or similar mechanism
> instead?
> 
> Just a few days ago I tried building mesa from experimental
> (otherwise there are severe graphics glitches on my platform) on
> bookworm and everything worked except its rust build dependencies.
> I had no luck trying to backport those parts of rust that I needed
> and even if it had worked, it would've meant backporting dozens of
> rust packages just to have a backport of mesa.
[...]

Another practical example is Python applications/libs increasingly
integrating performance or security critical routines (re)written in
Rust. The python-cryptography source package in sid build-depends on
cargo and a dozen Rust libs. I didn't bother to pull a rdeps list
for it, but can guarantee a vast swath of the python3-* packages in
Debian depend on python3-cryptography, and this particular problem
will only get worse as the CPython core devs see the rising
popularity of the externally-developed cryptography library as a
good reason to strip any remnants of cryptographic modules and
bindings from the stdlib.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature

Re: Proposal for how to deal with Go/Rust/etc security bugs

[Gioele Barabucci]

On 24/01/24 14:01, Luca Boccassi wrote:

how does that work for those applications that require rust, go and friends?
Are you proposing that everything that needs them should be be distributed by a
flatpak or similar mechanism instead?


Those applications are not shipped in the distribution. If somebody
wants to use them, they'll have to figure it out, just like for
everything else that is not shipped in the distribution, which is
already a subset of all available software in the world.


The risk is that that subset will get even smaller and miss out on new 
developments: Debian will then be stuck as a "C distribution" and with C 
& Co becoming more and more legacy, that means that Debian will become a 
"legacy distribution".


It is nice to know that, even if the paradigms are changing, one can 
still apt install caddy, etcd, acmetool, influxdb, prometheus, sq, 
firefox...


--
Gioele Barabucci

Re: Proposal for how to deal with Go/Rust/etc security bugs (was: Re: Limited security support for Go/Rust? Re ssh3)

[Luca Boccassi]

On Wed, 24 Jan 2024 at 12:26, Johannes Schauer Marin Rodrigues
 wrote:
>
> Hi,
>
> Quoting Luca Boccassi (2024-01-24 12:59:38)
> > There's always option B: recognize that the Rust/Go ecosystems are not
> > designed to be compatible with the Linux distributions model, and are 
> > instead
> > designed to be as convenient as possible for a _single_ application 
> > developer
> > and its users - at the detriment of everybody else - and for large
> > corporations that ship a handful of applications with swathes of engineers
> > that can manage the churn, and it is not made nor intended to scale to ~60k
> > packages or whatever number we have today in unstable. And simply stop
> > attempting to merge these two incompatible ecosystems against their will, at
> > the very least until and unless they reach feature and stability parity with
> > the C/C++ ecosystems - stable API/ABI and dynamic linking by default.
> >
> > There are many ways to ship applications today that are much better
> > suited for these models, like Flatpak, where the maintenance burden is
> > shifted onto those who choose to opt in to such ecosystems.
>
> how does that work for those applications that require rust, go and friends?
> Are you proposing that everything that needs them should be be distributed by 
> a
> flatpak or similar mechanism instead?

Those applications are not shipped in the distribution. If somebody
wants to use them, they'll have to figure it out, just like for
everything else that is not shipped in the distribution, which is
already a subset of all available software in the world.

> Just a few days ago I tried building mesa from experimental (otherwise there
> are severe graphics glitches on my platform) on bookworm and everything worked
> except its rust build dependencies.  I had no luck trying to backport those
> parts of rust that I needed and even if it had worked, it would've meant
> backporting dozens of rust packages just to have a backport of mesa. It seemed
> way simpler to just disable the mesa component that requires rust and call it 
> a
> day. But that probably doesn't work for all applications and maybe sometimes
> the component written in rust is actually what you want. And in case of mesa, 
> a
> flatpak of it probably would also not've helped as that would've meant that I
> need to run everything that I want to run with a more modern mesa based on 
> that
> flatpak, right?
>
> So how is option B a solution in practice?

You have found first-hand the exact problem with this ecosystem. Now
try to imagine doing that for 30k packages, all vendoring, pinning and
static linking against each other at different, incompatible versions.
Again, the solution in practice is to simply disable or patch out
those components, and if somebody needs them, they can complain to
upstream and ask them for a solution, if there is one. If there isn't,
though luck. And yes, that is not great - but neither are all other
options, so it seems much wiser to me to push responsibility where it
belongs - with the upstreams choosing to use such ecosystems, and the
owner of said ecosystems choosing to make them incompatible with the
distribution model, as they are in the best position to solve the
problem(s) that happen due to their design choices.

Re: Proposal for how to deal with Go/Rust/etc security bugs

[Praveen Arimbrathodiyil]

On 24/01/24 5:59 pm, Simon Josefsson wrote:

Does anyone know of a shared library in a Debian package written in Go?
I've only encountered the vendored approach to ship Go libraries.


libgovarnam1 is shipped as a shared library
https://packages.debian.org/sid/amd64/libgovarnam1/filelist



OpenPGP_0x8F53E0193B294B75.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Proposal for how to deal with Go/Rust/etc security bugs

[Simon Josefsson]

Luca Boccassi  writes:

>> Having reflected a bit, and learned through my own experience and
>> others' insights [1] that Go Build-Depends are not transitive, I'd like
>> to update my proposal on how to handle a security bug in any Go/Rust/etc
>> package and the resulting package rebuilds:
>
> There's always option B: recognize that the Rust/Go ecosystems are not
> designed to be compatible with the Linux distributions model

Definitely - that's roughly the model we have today, right?  So no
action needed to preserve status quo of option B.

I want to explore if there is a possibility to change status quo, and
what would be required to do so.

Given how often gnulib is vendored for C code in Debian, and other
similar examples, I don't think of this problem as purely a Go/Rust
problem.  The parallel argument that we should not support coreutils,
sed, tar, gzip etc because they included vendored copies of gnulib code
is not reasonable.

> and are instead designed to be as convenient as possible for a
> _single_ application developer and its users - at the detriment of
> everybody else - and for large corporations that ship a handful of
> applications with swathes of engineers that can manage the churn, and
> it is not made nor intended to scale to ~60k packages or whatever
> number we have today in unstable. And simply stop attempting to merge
> these two incompatible ecosystems against their will, at the very
> least until and unless they reach feature and stability parity with
> the C/C++ ecosystems - stable API/ABI and dynamic linking by default.

Go seems to have supported shared libraries since around ca 2015:

https://go.dev/talks/2015/state-of-go-may.slide#13
https://docs.google.com/document/d/1nr-TQHw_er6GOQRsF6T43GGhFDelrAP0NqSS_00RgZQ/edit

Does anyone know of a shared library in a Debian package written in Go?
I've only encountered the vendored approach to ship Go libraries.

> There are many ways to ship applications today that are much better
> suited for these models, like Flatpak, where the maintenance burden is
> shifted onto those who choose to opt in to such ecosystems.

Or simply 'go install ...', it works remarkably well.

However, this is orthogonal to how we support the Go code that is in
Debian already.

/Simon


signature.asc
Description: PGP signature

Re: Proposal for how to deal with Go/Rust/etc security bugs (was: Re: Limited security support for Go/Rust? Re ssh3)

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Luca Boccassi (2024-01-24 12:59:38)
> There's always option B: recognize that the Rust/Go ecosystems are not
> designed to be compatible with the Linux distributions model, and are instead
> designed to be as convenient as possible for a _single_ application developer
> and its users - at the detriment of everybody else - and for large
> corporations that ship a handful of applications with swathes of engineers
> that can manage the churn, and it is not made nor intended to scale to ~60k
> packages or whatever number we have today in unstable. And simply stop
> attempting to merge these two incompatible ecosystems against their will, at
> the very least until and unless they reach feature and stability parity with
> the C/C++ ecosystems - stable API/ABI and dynamic linking by default.
> 
> There are many ways to ship applications today that are much better
> suited for these models, like Flatpak, where the maintenance burden is
> shifted onto those who choose to opt in to such ecosystems.

how does that work for those applications that require rust, go and friends?
Are you proposing that everything that needs them should be be distributed by a
flatpak or similar mechanism instead?

Just a few days ago I tried building mesa from experimental (otherwise there
are severe graphics glitches on my platform) on bookworm and everything worked
except its rust build dependencies.  I had no luck trying to backport those
parts of rust that I needed and even if it had worked, it would've meant
backporting dozens of rust packages just to have a backport of mesa. It seemed
way simpler to just disable the mesa component that requires rust and call it a
day. But that probably doesn't work for all applications and maybe sometimes
the component written in rust is actually what you want. And in case of mesa, a
flatpak of it probably would also not've helped as that would've meant that I
need to run everything that I want to run with a more modern mesa based on that
flatpak, right?

So how is option B a solution in practice?

Thanks!

cheers, josch

signature.asc
Description: signature

Re: Proposal for how to deal with Go/Rust/etc security bugs (was: Re: Limited security support for Go/Rust? Re ssh3)

[Luca Boccassi]

On Wed, 24 Jan 2024 at 11:42, Simon Josefsson  wrote:
>
> Simon Josefsson  writes:
>
> >> > My naive approach on how to fix a security problem in package X
> >> > which is
> >> > statically embedded into other packages A, B, C, ... would be to
> >> > rebuild
> >> > the transitive closure of all packages that Build-Depends on X and
> >> > publish a security update for all those packages.
> ...
> > I realized that there is one problem with my approach: consider if
> > package A was built via Build-Depends package B of version X and that
> > later package B is upgraded to X+1 in Debian.  Then if a security
> > problem happens in B we need to rebuild A. It may be that package A no
> > longer builds due to some incompatibility between version X and X+1 of
> > B.  This would not be noticed until a full rebuild of an archive is
> > done, or when the security teams wants to rebuild the transitive
> > closure of the Build-Depends graph for a package.
>
> Having reflected a bit, and learned through my own experience and
> others' insights [1] that Go Build-Depends are not transitive, I'd like
> to update my proposal on how to handle a security bug in any Go/Rust/etc
> package and the resulting package rebuilds:

There's always option B: recognize that the Rust/Go ecosystems are not
designed to be compatible with the Linux distributions model, and are
instead designed to be as convenient as possible for a _single_
application developer and its users - at the detriment of everybody
else - and for large corporations that ship a handful of applications
with swathes of engineers that can manage the churn, and it is not
made nor intended to scale to ~60k packages or whatever number we have
today in unstable. And simply stop attempting to merge these two
incompatible ecosystems against their will, at the very least until
and unless they reach feature and stability parity with the C/C++
ecosystems - stable API/ABI and dynamic linking by default.

There are many ways to ship applications today that are much better
suited for these models, like Flatpak, where the maintenance burden is
shifted onto those who choose to opt in to such ecosystems.

Bug#1061425: ITP: iamb -- Matrix chat client that uses Vim keybindings

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 
X-Debbugs-Cc: debian-devel@lists.debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: iamb
  Version : 0.0.8
  Upstream Contact: Ulyssa 
* URL : https://iamb.chat/
* License : Apache-2.0
  Programming Lang: Rust
  Description : Matrix chat client that uses Vim keybindings

 iamb is a terminal-based client for Matrix for the Vim addict.
 You can edit messages, navigate windows and manage tabs
 in the same ways that your fingers are used to
 from your favorite text editor.

This package will be maintained in the collaborative debian section of
Salsa, at .
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmWw7iUACgkQLHwxRsGg
ASH50g/+NS9ZivOH2LjhBqR9wJYSBplB4WkacHYIiy6qNxz6mMD8exfAWtDSZP5V
96ABfcGuS2PIP6mTcfnA61DMep0mlbAQecZ3l2SxBEbqtpXcn8nsqRpKgg1vVWRd
3uIcd7PAnJB7+AdssOL664MoZMRAH+NchzeoGku/jOgjCI8gnaMNiR0BHA0k8McF
NN437JVBTx/cJOtlkMgbJtRr8D36J9fzJIfiJo3pjU9IRlSE13/pwa7HZTpnQ+DE
ckxU+Fi9xrnHFW0mc76n7nD8Wf5k4VGe/bzN6M1uodZpk0UFdCDR+F93AJTLz5y0
0VU7bkJX4cyGybOuMK6pP2x0p/05ErwtMxRcY7wYm+tqCL9T/SLuSZ3xnprwteTL
kWwQrpuoD/8PXbdtte2aC7g9brK8lXeo2FUOcQ+76xvRlM0j4hq2bHMnlnI1rN1l
u9fPI6HbOZ1UBmcM2BcBldOGOmzUJhjqAtCWY2Rdn2LAdcO7Ji+N7p13XKgwG6b3
cOpug96wPTUgXTFDLFn2ULrdL7sPJLcwzz0YA7BG3hubbMJv4KIuv0soC0Ih6iJ9
F5zg9OdsWkZFGYzYCXp7bEpQdRUZxj5MF69OmU7OgkU1a3KWcVQcNgBB8sgK8C77
P0RUoV3RaZaOk0thM8G3F0pi5JMwGzVV02oBRAuBfr8jUPiyq3A=
=2DPA
-END PGP SIGNATURE-

Re: Proposal for how to deal with Go/Rust/etc security bugs

[Praveen Arimbrathodiyil]

On 24/01/24 2:07 pm, Simon Josefsson wrote:

Yes, for a low-level Go package (e.g., golang-golang-x-net-dev), this
will mean rebuilding almost all of the Go packages in Debian and publish
them in a security advisory.

This algorithm can be optimized (i.e., reduce the number of packages to
publish in an advisory) by either of:

 1) using information from Built-Using: (which was not designed for
this purpose, so this is fragile) or *.buildinfo.

 2) by dropping all 'Architecture: all' packages that does not embedd
the buggy code.

The last optimization 2) would reduce the number of Go packages to
publish significantly, as it would drop most golang-*-dev packages.  I
think this actually makes this process feasible in practice, as there
are relatively few binary packages written in Go.


I was also wondering about this, the actual number of arch:any go 
packages is much smaller if we skip arch:all *-dev packages so this 
should be a smaller number of rebuilds than what is currently 
considered. We can make this even smaller by choosing a limited number 
of packages for security support, for example caddy, soh etc, which 
would already be better than not providing any security update at all.


OpenPGP_0x8F53E0193B294B75.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Proposal for how to deal with Go/Rust/etc security bugs (was: Re: Limited security support for Go/Rust? Re ssh3)

[Simon Josefsson]

Simon Josefsson  writes:

>> > My naive approach on how to fix a security problem in package X
>> > which is
>> > statically embedded into other packages A, B, C, ... would be to
>> > rebuild
>> > the transitive closure of all packages that Build-Depends on X and
>> > publish a security update for all those packages.
...
> I realized that there is one problem with my approach: consider if
> package A was built via Build-Depends package B of version X and that
> later package B is upgraded to X+1 in Debian.  Then if a security
> problem happens in B we need to rebuild A. It may be that package A no
> longer builds due to some incompatibility between version X and X+1 of
> B.  This would not be noticed until a full rebuild of an archive is
> done, or when the security teams wants to rebuild the transitive
> closure of the Build-Depends graph for a package.

Having reflected a bit, and learned through my own experience and
others' insights [1] that Go Build-Depends are not transitive, I'd like
to update my proposal on how to handle a security bug in any Go/Rust/etc
package and the resulting package rebuilds:

  To fix a security problem in package X, which is used during build
  (through statical linking, vendoring, or some other mechanism) to
  build package A, B, C, ... you need to rebuild all packages that
  Build-Depends on X (lets call this step 1) and all packages that
  Build-Depends on any of the packages that will be rebuilt during step
  1.  This rebuild process is iterated until no more packages remains to
  be rebuild, and all packages have been rebuilt using newly rebuild
  packages.  If there are cyclical dependencies (which unfortunately are
  common), you have to loop until all packages have been rebuilt with a
  clean dependency chain, and detect the loop and stop rebuilding.  If
  there are FTBFS errors during the rebuilds, this will have to be
  patched too.

Yes, for a low-level Go package (e.g., golang-golang-x-net-dev), this
will mean rebuilding almost all of the Go packages in Debian and publish
them in a security advisory.

This algorithm can be optimized (i.e., reduce the number of packages to
publish in an advisory) by either of:

1) using information from Built-Using: (which was not designed for
   this purpose, so this is fragile) or *.buildinfo.

2) by dropping all 'Architecture: all' packages that does not embedd
   the buggy code.

The last optimization 2) would reduce the number of Go packages to
publish significantly, as it would drop most golang-*-dev packages.  I
think this actually makes this process feasible in practice, as there
are relatively few binary packages written in Go.

This method applies to non-Go/Rust too, if there are such security
problems and reverse build chains.

I think all of this (except maybe the optimization 2) which requires
code comparisons) can be automated in a GitLab pipeline for higher
confidence of the result.

/Simon

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


signature.asc
Description: PGP signature