Re: How should we handle greenbone-security-assistant?
On Fri, Dec 18, 2020 at 05:12:53PM +0100, Jonas Smedegaard wrote: > Quoting Adrian Bunk (2020-12-18 15:36:23) > > On Fri, Dec 18, 2020 at 01:33:33PM +0100, Jonas Smedegaard wrote: > > > It is indeed not realistic to fit all fast-changing code projects > > > into Debian. We have made a few fast-paced projects like Firefox > > > fit, but in my opinion we did that in a problematic way: By > > > endorsing embedded code copies, which is painful to maintain. > > > > > > I think we should not relax our rules, but (improve our packages so > > > that we can) tighten our rules to apply more consistently - e.g. > > > avoid embedded code copies also in Firefox. > > > > Embedded code copies are the smallest problem with Firefox, and on > > that I would actually trust Mozilla to release fixes quickly. > > I do trust Mozilla to release fixes quickly - my point was a different > one: Mozilla and Google and GNOME and KDE each being quick to release > fixes for libusrsctp or some other embedded library is still different > from linking with a shared copy. Firefox in unstable is mostly using shared libraries, in (old)stable it is using some static libraries because Firefox wants more recent versions than are in the distribution. The big problem is that Firefox is not security supportable without upgrading to new upstream versions that are not on the same stable branch, such software is not suitable for distributions with security supported stable series like Debian or Ubuntu. > - Jonas cu Adrian
Re: How should we handle greenbone-security-assistant?
Quoting Adrian Bunk (2020-12-19 10:17:04) > On Fri, Dec 18, 2020 at 05:12:53PM +0100, Jonas Smedegaard wrote: > > Quoting Adrian Bunk (2020-12-18 15:36:23) > > > On Fri, Dec 18, 2020 at 01:33:33PM +0100, Jonas Smedegaard wrote: > > > > It is indeed not realistic to fit all fast-changing code > > > > projects into Debian. We have made a few fast-paced projects > > > > like Firefox fit, but in my opinion we did that in a problematic > > > > way: By endorsing embedded code copies, which is painful to > > > > maintain. > > > > > > > > I think we should not relax our rules, but (improve our packages > > > > so that we can) tighten our rules to apply more consistently - > > > > e.g. avoid embedded code copies also in Firefox. > > > > > > Embedded code copies are the smallest problem with Firefox, and on > > > that I would actually trust Mozilla to release fixes quickly. > > > > I do trust Mozilla to release fixes quickly - my point was a > > different one: Mozilla and Google and GNOME and KDE each being quick > > to release fixes for libusrsctp or some other embedded library is > > still different from linking with a shared copy. > > Firefox in unstable is mostly using shared libraries, in (old)stable > it is using some static libraries because Firefox wants more recent > versions than are in the distribution. > > The big problem is that Firefox is not security supportable without > upgrading to new upstream versions that are not on the same stable > branch, such software is not suitable for distributions with security > supported stable series like Debian or Ubuntu. Yes, Firefox initially use system-shared libraries and use locally embedded copies only when needed. Similar for Chromium and other packages (to a varying degree of "when needed"). Yes, keeping the application security supportable in a stable environment is the big problem. My point is that we currently address that big problem by effectively encourage locally embedding code copies, as our way of addressing that big problem: Firefox and Chromium are packaged as a single big self-contained thing including its web rendering engine, and can be security-maintained; Epiphany (a.k.a. GNOME Web) and other web browsers are packaged without embedding their web rendering engine, and those (webkitgtk and qtwebengine-opensource-src) loose security support. Firefox is not badly packaged. It works! But it works in a way that does not scale well - and I find it worrisome if big popular projects get preferential treatment in Debian. Possibly they don't. Possibly if 10 or 50 other packages began including local copies of library code to not _need_ to depend on system-shared code at a later stage of their lifecycle in Debian, we would happily accept that. But I highly doubt that, and it feels backwards to me to do it. janus is a fast-paced package. It links with libusrsctp and libsrtp2, and some upgrades require upgrades to those other libraries as well. Should I embed copies of those libraries into src:janus to ease a later upgrade while in stable Debian? Firefox and Chromium and webkitgtk and qtwebengine-opensource-src embed libusrsctp and libsrtp2. It works, and addressed "the big problem", but I think we should not undermine but find ways to embrace Debian Policy [§4.13]: > Some software packages include in their distribution convenience > copies of code from other software packages, generally so that users > compiling from source don’t have to download multiple packages. Debian > packages should not make use of these convenience copies unless the > included package is explicitly intended to be used in this way. If the > included code is already in the Debian archive in the form of a > library, the Debian packaging should ensure that binary packages > reference the libraries already in Debian and the convenience copy is > not used. If the included code is not already in Debian, it should be > packaged separately as a prerequisite if possible. - Jonas [§4.13]: https://www.debian.org/doc/debian-policy/ch-source.html#embedded-code-copies -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#977734: ITP: mediasoup -- general purpose WebRTC gateway
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-devel@lists.debian.org, Debian VoIP Team -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: mediasoup Version : 3.6.27 Upstream Author : Iñaki Baz Castillo * URL : https://mediasoup.org/ * License : ISC Programming Lang: C, JavaScript, TypeScript Description : general purpose WebRTC gateway mediasoup is a general purpose WebRTC Gateway with a minimal footprint. . As such, it provides no functionality per se other than implementing the means to set up a WebRTC media communication with a browser, exchanging JSON messages with it, and relaying RTP/RTCP and messages between browsers and the server-side application logic they are attached to. Any specific feature/application are implemented in server side plugins, that browsers contact via the gateway to take advantage of the functionality they provide. . Example uses for mediasoup are applications involving echo tests, conference bridges, media recorders, and SIP gateways. This package will be maintained in the VoIP team. - Jonas -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAl/eWD0ACgkQLHwxRsGg ASFSaw//aDnYz3yP9LwKg1eqaR6E6i43bE/U18hWJMPYtsnwbmf5SpSaf/QY7aPi 9Ga9n3d9a9K74PPUDqYcLfm0JS8vYtFzuQOImOjCZmSC4OYj9ZCWpI26dso8LTK6 szdCBOm0WwBAo+beRpNzaiTrdb9JuOvfTwMOpl8PUDoxz0Eku4eqSxRfCVCgNtgV ddnlEwhfROrhzl1ZybJROI1RgmrG6TPXOkPCEwUExHeRlb0Q92Btqz0dQUAzX6dE 59xd49Y/rR0tzbw0BIi1HaOlCB37mpqFgti69wkdIdc9cJt8PZta47XpxeajDSxB yzxfWzlhQNUKucJxB5x4J8e0O/Q5hPr49CWJCajendrgfC6gVijv1HUMWLCEQ3h0 TrOBhyrSA1QSz25Nr2HKUDpy9c4DTZImPM6BO2NKT2GtPybKajeDain0NT6So5Bf CJ+KrTjJ3GyPkUZXx+z/CWe4E+PSaOgHsq8BT1RLIP1FMTYArJwJdT31gZ/xU9NC 6PANihdirNupZG4H8uafKq04+NkPzq3iYjQaQlq6xKQYLS6X4BB/FSPLimTtjOR5 Sx/rwqZdG63yniXj/ekE+LIs4swuNb9tXc6hx2OU+BAOd2iPo/cY1urczrYVdxzR qOhF3/wCVLvJDuEQBodyz4TiDjEZr2xAvfXxw5O1G2QAkIfAwaM= =mpRM -END PGP SIGNATURE-
Re: Package dependency versions and consistency
On 19.12.20 01:25, Josh Triplett wrote: Jonas Smedegaard wrote: Quoting Raphael Hertzog (2020-12-17 13:16:14) Even if you package everything, you will never ever have the right combination of version of the various packages. What is possible to auto-compute is a coarse view of the work needed. In reality, most Nodejs modules declare too tight versioning for their dependencies, and in many cases it is adequate that a module is packaged even if not at the version declared as required. A concrete example is "ansi-styles" which is most likely working just fine in version 4.x. This is not at all as simple as it sounds, even on a small scale, let alone when multiplied by a few hundred dependencies. (Let's please not go on the standard tangent into complaints about the number of dependencies, because at the end of that tangent, people will still use fine-grained packages and dependencies per the standard best-practices of those communities, no matter the number or content of mails in this thread suggesting otherwise. The extremes of "package for a one-line function" are not the primary issue here; not every fine-grained dependency is that small, and the issues raised in this mail still apply whether you have 200 dependencies or 600. So let's take it as a given that packages *will* have hundreds of library dependencies, and try to make that more feasible.) Figuring out whether those dependencies are actually too specific or if they're required is a substantial amount of work by itself; the packaging metadata and dependency versions recorded upstream exist to declare the required version of dependencies, and there isn't typically a *second* way that upstream records "no, really, there's a reason for this dependency version requirement". This is hard enough in a statically typed language, where you can at least have the verification of seeing if it compiles with the older version (though the package might be relying on new semantics); with a dynamically typed language, you might not know that the older version of the dependency has caused a problem until runtime. As an upstream developer, the safest assumption when preparing your own dependencies is "well, it works with the version of the dependency I tested with, and assuming that component correctly follows semver, it should work with newer semver-compatible versions". To clarify something: I *don't* believe Debian should compromise on network access at build time. Debian package dependencies should be completely self-contained within the Debian archive. The aspect I'm concerned about here is that Debian pushes hard to force every single package to use *the same version* of a given dependency, even if the dependency has multiple incompatible versions (properly declared with different semver major numbers, equivalent to libraries with different SONAMEs). I'm not suggesting there should be 50 versions of a given library in the archive, but allowing 2-4 versions would greatly simplify packaging, and would allow such unification efforts to take place incrementally, via transitions *in the archive* and *in collaboration with upstream*, rather than *all at once before a new package can be uploaded*. (I also *completely* understand pushing back on having 2-4 versions of something like OpenSSL; that'd be a huge maintenance and security burden. That doesn't mean we couldn't have 2-4 semver-major versions of a library to emit ANSI color codes, and handle reducing that number via incremental porting in the archive rather than via prohibition in advance.) I think much of our resistance to allowing 2-4 distinct semver-major versions of a given library comes down to ELF shared libraries making it painful to have two versions of a library with distinct SONAMEs loaded at once, and while that can be worked around with symbol versioning, we've collectively experienced enough pain in such cases that we're hesitant to encourage it. Our policies have done a fair bit to mitigate that pain. But much of that pain is specific to ELF shared libraries and similar. And some of our packaging limitations are built around this (e.g. "one version of a given package at a time"), which in turn forces some of those same limitations onto ecosystems that don't share the problems that motivated those limitations in the first place. The dependency and library mechanisms of some other ecosystems, are designed to support having multiple distinct versions of libraries in the same address space, with fully automatic equivalents of symbol versioning. In Debian packaging, this issue typically results in one of three scenarios for every dependency (recursively): - Trying to port the package to work with older versions of dependencies. This incurs all of the burden mentioned above for determining if the older dependency actually suffices. On top of that, this may involve actual porting of code to not rely on the functionality of newer versions, which is very much wasted effort (
Re: Package dependency versions and consistency
Hi, On 19-12-2020 01:25, Josh Triplett wrote: > Given all of the above improvements, it'd be much more feasible for > tooling to help systematically unbundle and package dependencies, and to > help manage and transition those dependencies in the archive. Especially in the JavaScript arena, I think there is to gain without much overhead already in the current way of working. What if packages where multiple versions are in use would ship multiple versions *in the same binary package*? In my experience, the maintainer needs to link to the right directory anyways, if those are semver versioned directories, it would be clear (with a tiny bit of tooling maybe) which package needs which version. And if the maintainer of the shipping package wants to drop some, they could communicate about that. Maybe they could even ship a latest or recommended version for those packages where it's not absolutely important which version they get. No idea if this idea works for other areas. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#977739: ITP: golang-github-texttheater-golang-levenshtein -- An implementation of the Levenshtein algorithm in Go. Provides edit distances and edit scripts.
Package: wnpp Severity: wishlist Owner: Richard Lough * Package name: golang-github-texttheater-golang-levenshtein Version : 1.0.1-1 Upstream Author : Kilian Evang * URL : https://github.com/texttheater/golang-levenshtein * License : Expat Programming Lang: Go Description : An implementation of the Levenshtein algorithm in Go. Provides edit distances and edit scripts. golang-levenshtein An implementation of the Levenshtein algorithm in Go. Provides edit distances, edit scripts and ratios for strings (slices of runes). Installation$ go get github.com/texttheater/golang-levenshtein/levenshtein Documentation The documentation can be viewed online here: https://godoc.org/github.com/texttheater/golang-levenshtein/levenshtein See also For a package that is similar but more generic and provides more control, check out Daniël de Kok’s editdistance (https://github.com/danieldk/editdistance). TODO: perhaps reasoning
Bug#977740: ITP: paho.mqtt.cpp -- Eclipse Paho MQTT C++ client library
Package: wnpp Severity: wishlist Owner: Matthias Klein -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: paho.mqtt.cpp Version : 1.2 Upstream Author : Eclipse Paho Development Team * URL : https://github.com/eclipse/paho.mqtt.cpp * License : EPL-1.0 Programming Programming Lang: C++ Description : Eclipse Paho MQTT C++ client library This library enables C++11 applications to connect to an MQTT broker, publish messages to the broker, and to subscribe to topics and receive published messages. This library requires the Paho C library which is already packaged in debian: https://packages.debian.org/sid/libpaho-mqtt1.3 -BEGIN PGP SIGNATURE- iQJNBAEBCgA3FiEEjC6qGcnd04OdZq2u/7AEG+75lvAFAl/eb70ZHG1hdHRoaWFz LmtsZWluQGxpbnV4LmNvbQAKCRD/sAQb7vmW8Mz9D/wLhKKwevWHv8J927+xjqiE 9KbcoxoChjSTF6A3kjaypm/ZsnU9VlLJsamc44o4ZVupsJALocHoGu6vyY0YbNox bqH5nK20zBCxQNQ0FMhjG8EJjg2Dbrdwfn2QHAaMx6UmykBo+Ue2E4qNFY5RDMoy BSB3sA3EmzDA6JnAt0g0W9A29Lv075manybVEc87Lt7DTNQYPFuxAdyr4ocnATrX o5eVyDtjx+8kgnBOd4bB+XrnaYHAGwMkj2HJsdmt1+VLSPfcOujL0nWIpQitPsNw NO72OyT3ptUyx5AbPuhONmcMjSaSN2UuFptHdOyjI8KprqN1mdbK8AsfGeog2PGb Xtjrdaj4WLIcD8/tdqfGdAuw8i9lsLo+UUGOizjHeb3mxg4hM1rFcP7d2GIJTv1u lGR6VMwyHOcTevwc3iuHYmPz51DDZMM52HBS2g7D2zAdkkU4+lrpVizFtNRV5g6G SzX0bzLCtxts6vqmrPtfaia9b12Iq4ly6SPZG/ICZJj8nQwzaXV2KPJU8Ua/rUWQ yvb0pBu5kHySv8a3+gpxdlrccSpPlP1CQvEf9pmPFe2MbZkyB546ELgA9NvUDD81 +BYDy4nNiUbP8Kdsg5XHGjpJvNew3+QtINP6eKLT8M+xj2aUJAIDGUG320VP4BEP vc5wkGJWHQL4CqjLuBCbaw== =Y7lK -END PGP SIGNATURE-
Re: glibc 2.32 before bullseye?
Paul Wise left as an exercise for the reader: > On Fri, Dec 18, 2020 at 4:46 AM Nick Black wrote: > > I was wondering whether glibc ... > These seem like questions for the glibc maintainers, probably via a bug > report. indeed =] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977691 -- nick black -=- https://www.nick-black.com to make an apple pie from scratch, you need first invent a universe.
