Limited security support for Go/Rust? Re ssh3
Stephan Verbücheln writes: > On Sat, 30 Dec 2023 12:47:48 + Colin Watson > wrote: >> I also feel that something security-critical like this that's >> labelled by upstream as "still experimental" probably shouldn't >> be in a Debian release. > > It is written in Go. The problem of Go library support in Debian should > also be considered for a security-critical tool like this. > > https://www.debian.org/releases/bookworm/amd64/release-notes/ch-information.en.html#golang-static-linking Interesting -- what is the current thinking about this problem? The more I think about it, I think it seems unfair to categorize this as a Go/Rust problem. As an analogy, consider the ./configure scripts that is generated by autoconf during build of many packages. The script typically generate code that is put into config.h that is used (statically) during compilation of the binaries that are shipped by Debian. Consider further that these configure scripts would put security buggy into config.h, coming from autoconf internally or some wildly used M4 macros. How would the security team handle that situation? Perhaps by patching autoconf to fix the problem and rebuild all the packages that are affected by that bug, and release them as a (potentially large) security update. This is a similar situation to the Go/Rust problem that the link above describes. Yes I know, historically config.h has been quite small, so the problem hasn't been that significant, but have a look at a config.h from a couple of large project today. Compare an earlier large-scale-affecting build-tool bug in automake -- https://lists.gnu.org/archive/html/automake/2012-07/msg00022.html -- which happened to have mild consequences because 'make distcheck' is rarely run by most users or even during package builds, and the generated code didn't end up in the installed binaries. But it could happen in a 'make all' or a 'make check' target too, or affect code that actually influence the installed binaries. You could also compare how the source-level reuse-library gnulib is used by many essential packages (coreutils, grep, sed, awk, tar, etc), with large code-reuse that influences the installed binaries. A security sensitive bug in gnulib would require rebuild of many packages. My suggestion is that we relax or remove the Go/Rust statement in future release notes. /Simon signature.asc Description: PGP signature
Bug#1060793: ITP: node-luxon -- Wrapper for JavaScript dates and times
Package: wnpp Severity: wishlist Owner: Jérémy Lal X-Debbugs-Cc: debian-devel@lists.debian.org, Debian Javascript Maintainers * Package name: node-luxon Version : 3.4.4 Upstream Contact: https://github.com/moment/luxon/issues * URL : https://moment.github.io/luxon/ * License : Expat Programming Lang: JavaScript Description : Wrapper for JavaScript dates and times Luxon provides a set of powerful, modern, and friendly wrappers for DateTimes, Durations and Intervals. The API is immutable, chainable, and unambiguous. It uses native time zones and internationalization. Luxon is often used in webapps. It will be maintained within Javascript team. In particular I need to upload to Debian to use it in the front-end of AWX package.
Re: Limited security support for Go/Rust? Re ssh3
On Sun, Jan 14, 2024 at 10:47:18AM +0100, Simon Josefsson wrote: > Stephan Verbücheln writes: > > > On Sat, 30 Dec 2023 12:47:48 + Colin Watson > > wrote: > >> I also feel that something security-critical like this that's > >> labelled by upstream as "still experimental" probably shouldn't > >> be in a Debian release. > > > > It is written in Go. The problem of Go library support in Debian should > > also be considered for a security-critical tool like this. > > > > https://www.debian.org/releases/bookworm/amd64/release-notes/ch-information.en.html#golang-static-linking > > Interesting -- what is the current thinking about this problem? > > The more I think about it, I think it seems unfair to categorize this as > a Go/Rust problem. +1. Container packages such as docker and podman are also golang packages and also security critical. > ... > My suggestion is that we relax or remove the Go/Rust statement in future > release notes. Or we could as well look at improving the infrastructure to deal with them. Best, Nilesh signature.asc Description: PGP signature
Re: Limited security support for Go/Rust? Re ssh3
On Sun, 2024-01-14 at 10:47 +0100, Simon Josefsson wrote: > The more I think about it, I think it seems unfair to categorize this > as a Go/Rust problem. The point is that it should be possible all packages in Debian without dependencies which are outside of Debian. The same problem exists with all programs that depend on external dependency managers which manage a large number of small libraries which are changing all the time. These dependencies are a moving target hard to include into Debian stable. This is not only making updates but also reproducible builds harder. More examples for this are Node NPM, Python PIP, Ruby Gems etc. Go and Rust are different than NPM and Python for two reasons: - Go and Rust are used for more low-level programs where stability matters even more. - Go and Rust use static linking. > Interesting -- what is the current thinking about this problem? I think the current plan is to automatically update Debian packages of Go/Rust libraries in a similar way as it is done for Python. However, the static linking makes this different from Python, as these packages are build dependencies rather than runtime dependencies. So all reverse dependencies have to be rebuild in some way. I do not know what the status/progress of this project is. Regards Stephan signature.asc Description: This is a digitally signed message part
Re: Limited security support for Go/Rust? Re ssh3
Hi Simon On Sun, Jan 14, 2024 at 10:47:18AM +0100, Simon Josefsson wrote: > As an analogy, consider the ./configure scripts that is generated by > autoconf during build of many packages. The script typically generate > code that is put into config.h that is used (statically) during > compilation of the binaries that are shipped by Debian. Could you show an example, where there is actually code injcted in this stage? And then, this is vendoring, not static linking. > You could also compare how the source-level reuse-library gnulib is used > by many essential packages (coreutils, grep, sed, awk, tar, etc), with > large code-reuse that influences the installed binaries. A security > sensitive bug in gnulib would require rebuild of many packages. That is not static linking, this is vendoring. And can you show that GNU utils don't fix security bugs on this vendored lib? > My suggestion is that we relax or remove the Go/Rust statement in future > release notes. No. You described completely different circumstances. Or do you have a practical solution for the static linking problem, not the vendoring problem that you actually compared it against? Bastian -- A father doesn't destroy his children. -- Lt. Carolyn Palamas, "Who Mourns for Adonais?", stardate 3468.1.
Re: Bug#1059618: ITP: ssh3 -- faster and rich secure shell using HTTP/3
On Fri, Dec 29, 2023 at 11:30:14AM +0100, Simon Josefsson wrote: > * Package name: ssh3 This package name is clearly not acceptable. SSH is a well known name and this project is completely unrelated to it. So this is an accademic project. I would question that it actually solves the same problem as SSH does. The paper might also be missleading. They compare session setup time, but don't even describe the used parameters. They don't describe a way to use real authentication, instead they just refer to HTTP, which does not specify anything equivalent to what SSH uses by default. > - Significantly faster session establishment Questionable. > - New HTTP authentication methods such as OAuth 2.0 and OpenID Connect > in addition to classical SSH authentication In addition? I don't see any way to use authentication similar to SSH in this. But maybe just show where I can use sk-ssh-ed25...@openssh.com authentication, which is a modern one, with this. > - Robustness to port scanning attacks: your SSH3 server can be made > invisible to other Internet users You still have a HTTP listener that can be seen. Bastian -- It would be illogical to assume that all conditions remain stable. -- Spock, "The Enterprise Incident", stardate 5027.3
Re: Bug#1059618: ITP: ssh3 -- faster and rich secure shell using HTTP/3
Bastian Blank writes: > On Fri, Dec 29, 2023 at 11:30:14AM +0100, Simon Josefsson wrote: >> * Package name: ssh3 > > This package name is clearly not acceptable. SSH is a well known name > and this project is completely unrelated to it. Agreed. Packagers have settled on using 'soh' for the name, see: https://github.com/francoismichel/ssh3/issues/79 https://github.com/francoismichel/ssh3/pull/96 Once 0.1.5 is released, I will try to update the package to use the new name. It doesn't seem to collide with anything in Debian, as far as I can tell. It would be nice to have confirmation other distributions are going to use the same name, but I think we have that in the discussion above. Thoughts? Hyperbole in package descriptions are common, the current text is from the upstream authors and I think it makes sense to copy that in the package description. If you can think of some improvement, consider submitting a patch: https://salsa.debian.org/go-team/packages/ssh3 /Simon signature.asc Description: PGP signature
Re: Limited security support for Go/Rust? Re ssh3
Bastian Blank writes: > Hi Simon > > On Sun, Jan 14, 2024 at 10:47:18AM +0100, Simon Josefsson wrote: >> As an analogy, consider the ./configure scripts that is generated by >> autoconf during build of many packages. The script typically generate >> code that is put into config.h that is used (statically) during >> compilation of the binaries that are shipped by Debian. > > Could you show an example, where there is actually code injcted in this > stage? And then, this is vendoring, not static linking. > >> You could also compare how the source-level reuse-library gnulib is used >> by many essential packages (coreutils, grep, sed, awk, tar, etc), with >> large code-reuse that influences the installed binaries. A security >> sensitive bug in gnulib would require rebuild of many packages. > > That is not static linking, this is vendoring. And can you show that > GNU utils don't fix security bugs on this vendored lib? > >> My suggestion is that we relax or remove the Go/Rust statement in future >> release notes. > > No. You described completely different circumstances. > > Or do you have a practical solution for the static linking problem, not > the vendoring problem that you actually compared it against? Right, these are slightly different technical problems, but as far as the brief discussion in the release notes -- https://www.debian.org/releases/bookworm/amd64/release-notes/ch-information.en.html#golang-static-linking -- I think the relevant aspect is identical: package X in Debian contains an embedded copy of code whose corresponding source code is in package Y in Debian, and fixing a security problem in Y will require rebuilding X and the entire dependency chain between X and Y that carry the code that ends up in X. Isn't that what the text refers to? Vendoring and static linking are two examples of the same problem that the security team may encounter. The problem with dependencies are more obvious for Go/Rust code but I think we always have had that problem anyway. As for solutions, isn't the solution to both vendoring or statical linking the obvious one? You will have to rebuild all packages that contain the security vulnerability. Maybe I'm missing how these two problems result in different problems for the security team? /Simon signature.asc Description: PGP signature
Bug#1060805: ITP: pusimp -- prevent user-site imports
Package: wnpp Severity: wishlist Owner: Francesco Ballarin X-Debbugs-Cc: debian-devel@lists.debian.org, francesco.balla...@unicatt.it * Package name: pusimp Version : 0.1.0 Upstream Contact: Francesco Ballarin * URL : https://github.com/python-pusimp/pusimp * License : MIT Programming Lang: Python Description : prevent user-site imports pusimp is a python library to prevent user-site imports of specific dependencies of a package. The typical scenario for using pusimp is in combination with a system manager (e.g., apt for Debian), to prevent dependencies from being loaded from user-site instead of the location provided by the system manager. We designed pusimp with in mind the specific use case of the FEniCS project. It happens often that users post messages at the FEniCS discourse forum https://fenicsproject.discourse.group/ asking why their ubuntu/debian installation is not working correctly, and several times this is due to the presence of user-made installation attempts in user-site locations. We thus initially plan to use pusimp in the python3-dolfin and python3-dolfinx packages, but the logic behind pusimp is purposely simple and general. The package will be maintained at https://salsa.debian.org/python-team/packages/pusimp in collaboration with my sponsor Drew Parsons and the Debian Python Team
Re: Limited security support for Go/Rust? Re ssh3
Simon Josefsson wrote: > Isn't that what the text refers to? Vendoring and static linking are > two examples of the same problem that the security team may encounter. > The problem with dependencies are more obvious for Go/Rust code but I > think we always have had that problem anyway. Another example of this class of problem is header only C++ libraries. -- Robert Edmonds edmo...@debian.org
Bug#1060810: ITP: golang-github-sassoftware-go-rpmutils -- Golang implementation of parsing RPM packages
Package: wnpp Severity: wishlist Owner: Simon Josefsson * Package name: golang-github-sassoftware-go-rpmutils Version : 0.2.0-1 Upstream Author : SAS Institute, Inc. * URL : https://github.com/sassoftware/go-rpmutils * License : Apache-2.0 Programming Lang: Go Description : Golang implementation of parsing RPM packages go-rpmutils is a library written in go (http://golang.org) for parsing and extracting content from RPMs (http://www.rpm.org). . go-rpmutils provides a few interfaces for handling RPM packages. There is a highlevel Rpm struct that provides access to the RPM header and CPIO (https://en.wikipedia.org/wiki/Cpio) payload. The CPIO payload can be extracted to a filesystem location via the ExpandPayload function or through a Reader interface, similar to the tar implementation (https://golang.org/pkg/archive/tar/) in the go standard library. I hope to maintain this package as part of Debian Go Packaging Team: https://salsa.debian.org/go-team/packages/golang-github-sassoftware-go-rpmutils /Simon signature.asc Description: PGP signature
Bug#1060813: ITP: golang-github-qur-ar -- Golang ar archive file library
Package: wnpp Severity: wishlist Owner: Simon Josefsson * Package name: golang-github-qur-ar Version : 0.0~git20130629.282534b-1 Upstream Author : Blake Smith, Julian Phillips * URL : https://github.com/qur/ar * License : Expat Programming Lang: Go Description : Golang ar archive file library Golang ar (archive) file reader . This is a simple library for reading and writing ar (http://en.wikipedia.org/wiki/Ar_(Unix)) files in common format. It is influenced heavily in style and interface from the golang tar (http://golang.org/pkg/archive/tar/) package. I hope to maintain this package as part of Debian Go Packaging Team: https://salsa.debian.org/go-team/packages/golang-github-qur-ar /Simon signature.asc Description: PGP signature
Bug#1060815: ITP: relic -- digitally sign Linux/Java/Windows packages
Package: wnpp Severity: wishlist Owner: Simon Josefsson * Package name: relic Version : 7.6.1-1 Upstream Author : SAS Institute, Inc. * URL : https://github.com/sassoftware/relic * License : Apache-2.0 Programming Lang: Go Description : digitally sign Linux/Java/Windows packages relic is a multi-tool and server for package signing and working with hardware security modules (HSMs). . Package types . * RPM - RedHat packages * DEB - Debian packages * JAR - Java archives * EXE (PE/COFF) - Windows executable * MSI - Windows installer * appx, appxbundle - Windows universal application * CAB - Windows cabinet file * CAT - Windows security catalog * XAP - Silverlight and legacy Windows Phone applications * PS1, PS1XML, MOF, etc. - Microsoft Powershell scripts and modules * manifest, application - Microsoft ClickOnce manifest * VSIX - Visual Studio extension * Mach-O - macOS/iOS signed executables * DMG, PKG - macOS disk images / installer packages * APK - Android package * PGP - inline, detached or cleartext signature of data . Token types . relic can work with several types of token: . * pkcs11 - Industry standard PKCS#11 HSM interface using shared object files * Cloud services - AWS, Azure and Google Cloud managed keys * scdaemon - The GnuPG scdaemon service can enable access to OpenPGP cards (such as Yubikey NEO) * file - Private keys stored in a password-protected file . Features . Relic is primarily meant to operate as a signing server, allowing clients to authenticate with a TLS certificate and sign packages remotely. It can also be used as a standalone signing tool. . Other features include: . * Generating and importing keys in the token * Importing certificate chains from a PKCS#12 file * Creating X509 certificate signing requests (CSR) and self-signed certificates * Limited X509 CA support -- signing CSRs and cross-signing certificates * Creating simple PGP public keys * RSA and ECDSA supported for all signature types * Verify signatures, certificate chains and timestamps on all supported package types * Sending audit logs to an AMQP broker, with an optional sealing signature * Save token PINs in the system keyring . Linux, Windows and MacOS are supported. Other platforms probably work as well. . relic is tested using libsofthsm2 and Gemalto SafeNet Network HSM (Luna SA). I hope to maintain this package as part of Debian Go Packaging Team: https://salsa.debian.org/go-team/packages/relic /Simon signature.asc Description: PGP signature
Bug#1060816: ITP: golang-github-shibumi-go-pathspec -- gitignore-style pathspec pattern matching in Go
Package: wnpp Severity: wishlist Owner: Simon Josefsson * Package name: golang-github-shibumi-go-pathspec Version : 1.3.0-1 Upstream Author : Sander van Harmelen, Christian Rebischke * URL : https://github.com/shibumi/go-pathspec * License : Apache-2.0 Programming Lang: Go Description : gitignore-style pathspec pattern matching in Go go-pathspec implements gitignore-style pattern matching for paths. I hope to maintain this package as part of Debian Go Packaging Team: https://salsa.debian.org/go-team/packages/golang-github-shibumi-go-pathspec/ /Simon signature.asc Description: PGP signature
Bug#1060817: ITP: golang-github-spiffe-go-spiffe -- Golang library for SPIFFE support
Package: wnpp Severity: wishlist Owner: Simon Josefsson * Package name: golang-github-spiffe-go-spiffe Version : 2.1.6-1 Upstream Author : Agustín Martínez Fayó, Andrew Harding, et al * URL : https://github.com/spiffe/go-spiffe * License : Apache-2.0 Programming Lang: Go Description : Golang library for SPIFFE support This library is a convenient Go library for working with SPIFFE (https://spiffe.io/). . It leverages the SPIFFE Workload API (https://github.com/spiffe/spiffe/blob/main/standards/SPIFFE_Workload_API.md), providing high level functionality that includes: . * Establishing mutually authenticated TLS (**mTLS**) between workloads powered by SPIFFE. * Obtaining and validating X509-SVIDs (https://github.com/spiffe/spiffe/blob/main/standards/X509-SVID.md) and JWT-SVIDs (https://github.com/spiffe/spiffe/blob/main/standards/JWT- SVID.md). * Federating trust between trust domains using SPIFFE bundles (https://github.com/spiffe/spiffe/blob/main/standards/SPIFFE_Trust_Domain_and_Bundle.md#3- spiffe-bundles). * Bundle management. I hope to maintain this package as part of Debian Go Packaging Team: https://salsa.debian.org/go-team/packages/golang-github-spiffe-go-spiffe/ /Simon signature.asc Description: PGP signature
Bug#1060818: ITP: in-toto-golang -- framework for software supply chain integrity
Package: wnpp Severity: wishlist Owner: Simon Josefsson * Package name: in-toto-golang Version : 0.9.0-1 Upstream Author : Aditya Sirish, Christian Rebischke, Lukas Pühringer, et al * URL : https://github.com/in-toto/in-toto-golang * License : Apache-2.0 Programming Lang: Go Description : framework for software supply chain integrity Go implementation of in-toto I hope to maintain this package as part of Debian Go Packaging Team: https://salsa.debian.org/go-team/packages/in-toto-golang/ /Simon signature.asc Description: PGP signature
Bug#1060819: ITP: golang-github-zeebo-errs -- errs is a package for making errors friendly and easy
Package: wnpp Severity: wishlist Owner: Simon Josefsson * Package name: golang-github-zeebo-errs Version : 1.3.0-1 Upstream Author : Jeff Wendling * URL : https://github.com/zeebo/errs * License : Expat Programming Lang: Go Description : errs is a Go library for making errors friendly and easy errs is a package for making errors friendly and easy. Errors come with a stack trace that is only printed when a "+" character is used in the format string. This should retain the benefits of being able to diagnose where and why errors happen, without all of the noise of printing a stack trace in every situation. I hope to maintain this package as part of Debian Go Packaging Team: https://salsa.debian.org/go-team/packages/golang-github-zeebo-errs/ /Simon signature.asc Description: PGP signature
Bug#1060820: ITP: golang-github-cyberphone-json-canonicalization -- JSON Canonicalization Scheme (JCS) (Go library)
Package: wnpp Severity: wishlist Owner: Simon Josefsson * Package name: golang-github-cyberphone-json-canonicalization Version : 0.0~git20220623.57a0ce2-1 Upstream Author : Anders Rundgren * URL : https://github.com/cyberphone/json-canonicalization * License : Apache-2.0 Programming Lang: Go Description : JSON Canonicalization Scheme (JCS) (Go library) Cryptographic operations like hashing and signing depend on that the target data does not change during serialization, transport, or parsing. By applying the rules defined by JCS (JSON Canonicalization Scheme), data provided in the JSON [RFC8259 (https://tools.ietf.org/html/rfc8259)] format can be exchanged "as is", while still being subject to secure cryptographic operations. JCS achieves this by building on the serialization formats for JSON primitives as defined by ECMAScript [ES (https://ecma- international.org/ecma-262/)], constraining JSON data to the I-JSON [RFC7493 (https://tools.ietf.org/html//rfc7493)] subset, and through a platform independent property sorting scheme. . Public RFC: (https://tools.ietf.org/html/rfc8785) . The JSON Canonicalization Scheme concept in a nutshell: . * Serialization of primitive JSON data types using methods compatible with ECMAScript's JSON.stringify() * Lexicographic sorting of JSON Object properties in a *recursive* process * JSON Array data is also subject to canonicalization, *but element order remains untouched* I hope to maintain this package as part of Debian Go Packaging Team: https://salsa.debian.org/go-team/packages/golang-github-cyberphone-json-canonicalization /Simon signature.asc Description: PGP signature
Bug#1060830: ITP: gpu-burn -- Multi-GPU CUDA stress test
Package: wnpp Severity: wishlist Owner: Gürkan Myczko X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: gpu-burn Version : 0+git20240115+ds Upstream Authors: Ville Timonen URL : https://github.com/wilicc/gpu-burn * License : BSD-2-clause Description : Multi-GPU CUDA stress test This allows you to run a stress test on your GPUs. Memory usage can be controlled by absolute number or percentage. Also allows to run on specific GPU, useful if you have mixed multi GPU system.
