Re: Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)
Noah Meyerhans wrote: > On Sun, Dec 05, 2021 at 07:58:17PM +0300, Dmitry Alexandrov wrote: >> >> So what's happening with chromium in both sid and stable? I saw on >> >> d-release that it was removed from testing (#998676 and #998732), with a >> >> discussion about ending security support for it in stable. >> > >> > The problem really is lack of maintenance. In my opinion, chromium >> > deserves an active *team* to support it in Debian. <...> The security >> > team doesn't have the bandwidth to do it themselves, they need a team to >> > help them. >> >> Sorry for a silly question, but whatʼs so wrong with the build done by >> linuxmint.com [1], so Debian needs a whole team to duplicate their effort? >> Itʼs for Debian 10 (i. e. oldstable) as of now, but works fine at Sid in my >> (limited) experience. > > Well, you can start with the fact that the Mint chromium source packages > don't even include the chromium source, If the fact is that their ad-hoc downloader does not generate orig tarball, I fail to see much trouble here. They are using the same `chromium-browser-official` releases. > let alone the sources for all the other things they build (NodeJS, and more). Well, they actually do not build NodeJS, but use a blob from nodejs.org (just like Google does). Nothing good, of course, but I hope itʼs not the case that Chromium build fails when NodeJS is actually built from sources that are supposed to correspond to that blob? Or had nobody tried that? If the latter, why? Is there some policy, that mandates that preinstalled node(1) must be used? > One lesson we may take from Mint, though, is that it's not worth trying to > patch Chromium as much as we'd like. Anything that we can do to simplify the > Chromium packaging will help us keep the package up-to-date, which in turn > will help us keep our users safer. In my opinion, we should be pretty > aggressive about dropping as many of the Chromium patches as possible, even > if that means we link against bundled/vendored dependencies. Indeed. As a passer-by I really wonder why that path had been taken at all in the first place. If Chromium devs are into hard-pinning dependencies, they presumably have good reasons to do that. > Legal/licensing considerations are still important and I don't know if we > actually *can* ship builds based on the bundled stuff. I cannot imagine how it can be illegal for Debian what is legal for Google or Flathub in this case. Were there some prior discussions about that? signature.asc Description: PGP signature
Re: Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)
Noah Meyerhans wrote: > The biggest difficulty, as far as I can tell from my look at Chromium from > several months ago, is that our patch set [1] needs a lot of attention with > every chromium release. And let me ask another silly question: where can we actually see a CI log for a failed build? buildd.d.o only features the latest successful one (for 93rd Chromium). signature.asc Description: PGP signature
Re: Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)
On Tue, Dec 07, 2021 at 08:55:00AM +0100, Tomas Pospisek wrote: > I note that Steinar Gunderson [1] is now employed by Google to work on > Chrome, so maybe there could be hope talking to him? Hi, It's right that I'm just joining the Chromium team, although probably not in an area that is interesting to you (Style & Font). (And of course, I don't really have a say in anything yet, and I don't know anyone yet :-) ) I don't have the context here; what specifically is it that you're interested in getting fixed? /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#1001275: ITP: obs-downstream-keyer -- plugin for OBS Studio that adds a Downstream Keyer (DSK) dock
Package: wnpp Severity: wishlist Owner: Joao Eriberto Mota Filho X-Debbugs-Cc: debian-devel@lists.debian.org, exel...@hotmail.com * Package name: obs-downstream-keyer Version : 0.2.1 Upstream Author : Exeldro * URL : https://obsproject.com/forum/resources/downstream-keyer.1254/ * License : GPL-2 Programming Lang: C++ Description : plugin for OBS Studio that adds a Downstream Keyer (DSK) dock This plugin allows OBS to create overlays. Overlays are objects over a scene. Changing this scene will keep the overlay. This resource can be used to show logos, news or to show chat comments in live streams (there are some tutorials in the Internet to learn about the integration between this plugin and web browsers).
Re: Using release-monitoring.org [was: uscan roadmap]
On Sat, Dec 04, 2021 at 02:43:56AM +, Scott Kitterman wrote:
> I think that there's a security consideration associated with all these
> proposals for externalizing finding upstream updates. Currently watch files
> and at least the redirectors I know of all run on Debian infrastructure or on
> the systems of the Debian person doing the update.
I don't see how? At least repology just tells you "there is a new
upstream release", it doesn't tell you where to get it. It's up to the
maintainer to know where to download a new release.
Obviously if upstream is compromised and a new "release" is produced
that contains malicious code then there is a problem, but that is a
problem that is neither exacerbated nor mitigated by using repology.
> If one of these services were ever compromised it would provide a
> vector for offering substitute upstream code (at least for the cases
> where upstream releases aren't both signed by upstream and verified in
> Debian). I find that prospect concerning.
Validating that upstream releases are valid is part of the job of being
a maintainer in Debian. Having some helper service that tells you there
is a new release doesn't change that.
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
Re: Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)
Hi Steinar, On 07.12.21 10:07, Steinar H. Gunderson wrote: On Tue, Dec 07, 2021 at 08:55:00AM +0100, Tomas Pospisek wrote: I note that Steinar Gunderson [1] is now employed by Google to work on Chrome, so maybe there could be hope talking to him? It's right that I'm just joining the Chromium team, although probably not in an area that is interesting to you (Style & Font). (And of course, I don't really have a say in anything yet, and I don't know anyone yet :-) ) I don't have the context here; what specifically is it that you're interested in getting fixed? problem explanation starts at [1]. Let me try to summarize (those in the known please correct me): * chromium in Debian is *way* behind upstream * many security issues that are fixed upstream but not in Debian * chromium maintenance team is too small wrt to maintenance load * Debian is carrying many patches * Debian has reported bugs and patches upstream in the bug tracker * at least some build/build-options related * no feedback at all from upstream, issues persist * upstream's perception and attention seems to be limited to internal bug tracker So you being a DD and soon at work on Chromium the hope was that maybe you could conduct some of upstream love to care about the world outside of Google (?), here in particular Debian's effort to provide Chromium to its users... to help that effort. *t [1] https://lists.debian.org/debian-devel/2021/12/msg00079.html
Re: Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)
On Tue, Dec 07, 2021 at 07:05:29PM +0100, Tomas Pospisek wrote: > So you being a DD and soon at work on Chromium the hope was that maybe you > could conduct some of upstream love to care about the world outside of > Google (?), here in particular Debian's effort to provide Chromium to its > users... to help that effort. Hi, Obviously I cannot promise anything here; I'm currently even more in the dark than you. :-) But if there's a list of relevant bugs somewhere, I at least have a place to try to understand the issues at hand. /* Steinar */ -- Homepage: https://www.sesse.net/
Re: Using release-monitoring.org [was: uscan roadmap]
On Sat, Dec 4, 2021 at 3:34 AM Paul Wise wrote: > > Repology gets you mappings for all the source packages in Debian in one > download (assuming it has an export of the mappings, that may need to > be added), while the Anitya mapping requires a human to manually add a > mapping for each of the thousands of source packages in Debian. Not all > maintainers are going to bother and repetitive clicking is going to get > boring for the folks trying to make up for that. I'm sure there would be a way to automate this with repology data. > > Also, mapping on Repology sometimes needs to be adjusted manually. And > > sometimes they disagree and instead tell you to rename the source > > package in the distro (happened to me once), which is not really > > viable in Debian. > > I wasn't aware of the renaming part, seems kind of weird. See e.g. [1]: "Will not merge: Modules (e.g. python) without consistent prefix (e.g. python- or python3-) (common problem for Slackbuilds and Debian source packages). [...]" > > Yes it can't, but also I don't think this is something *release > > monitoring* should do. It is definitely a good use case and that is > > why there is a link to repology on the tracker (called "other > > distros"), but it has IMHO nothing to do with *automatic* release > > monitoring. Don't get me wrong, I actually like repology exactly for > > this particular reason. > > I was taking the thread topic to be the slightly more general area of > "monitoring when a package needs updating to a new upstream release, > snapshot or fork". New VCS snapshots in other distros fits that IMO. Ah right I see, I guess we then should separate more between fetching the tarball and scanning for versions to inform the maintainer - I don't think that these necessarily need to use the same technique. For informing the maintainer, repology might as well be an additional very useful tool. > The other issue with using Anitya is that Debian and Fedora have > different policies and culture for choosing which upstream versions to > update to. Debian strongly prefers LTS versions while Fedora are all > about the latest and greatest, which is a bit of a culture clash and is > likely to mean for some packages we couldn't use Anitya. I don't think this is an issue here - see [2]. The response differentiates between stable versions and other versions. I'm not sure how RCs are handled, but it would not be that difficult to implement. > In addition to independence there is the issue Jonas mentioned > elsewhere in the initial uscan thread that some Debian people prefer > the info to be maintained in the source package instead of elsewhere. Of course this would be optional. Regarding bootstrapping it might not be that good of an idea to use it for essential packages anyway. > > This sounds more reasonable to me than writing a tool that converts a > > new standard to the old one just as backup. > > Given the above, perhaps a way to sync a locally stored file and the > Anitya one, and then have uscan understand the Anitya format? I've been looking at the api (see [2]) for a bit and while not trying it out myself, afaik there is no functionality to download a tarball. While I like the idea of release-monitoring, I now feel like it doesn't fulfill the needs of Debian and probably newer will. So putting all watch files in a single salsa repo probably makes more sense, or something similar to offload it. On Sat, Dec 4, 2021 at 3:44 AM Scott Kitterman wrote: > > I think that there's a security consideration associated with all these > proposals for externalizing finding upstream updates. Currently watch files > and at least the redirectors I know of all run on Debian infrastructure or on > the systems of the Debian person doing the update. > > If one of these services were ever compromised it would provide a vector for > offering substitute upstream code (at least for the cases where upstream > releases aren't both signed by upstream and verified in Debian). I find that > prospect concerning. Good point, but I think this can be mitigated relatively easily - just always print the url of the tarball that is downloaded (which is a good idea anyway). The maintainer should know the url where the sources are hosted, and if the printed url somehow looks weird, it can be easily checked. Stephan [1] https://repology.org/project/symfit/report [2] https://release-monitoring.org/static/docs/api.html#post--api-v2-versions-
Re: Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)
On 07.12.21 19:14, Steinar H. Gunderson wrote: On Tue, Dec 07, 2021 at 07:05:29PM +0100, Tomas Pospisek wrote: So you being a DD and soon at work on Chromium the hope was that maybe you could conduct some of upstream love to care about the world outside of Google (?), here in particular Debian's effort to provide Chromium to its users... to help that effort. Obviously I cannot promise anything here; I'm currently even more in the dark than you. :-) But if there's a list of relevant bugs somewhere, I at least have a place to try to understand the issues at hand. I think it'd be best if Debian's chromium maintainers (see the recipients of this email) would reply to this question, however if you go to chromium's BTS page [1] then all the bug reports that have a "↝" (a wavy arrow) have been forwarded upstream and - judging by the fact that the bugs are still open in the BTS - have probably not been dealt with upstream. *t [1] https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=chromium;dist=unstable PS: I have included Mattia Rizzolo, Michael Gilbert and the Debian Chromium Team directly in the recipients, to be sure they see this email. I do hope you all do not mind.
ungoogled-chromium? [was: Re: Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)]
On 06.12.21 20:43, Noah Meyerhans wrote: On Sun, Dec 05, 2021 at 07:58:17PM +0300, Dmitry Alexandrov wrote: So what's happening with chromium in both sid and stable? I saw on d-release that it was removed from testing (#998676 and #998732), with a discussion about ending security support for it in stable. The problem really is lack of maintenance. In my opinion, chromium deserves an active *team* to support it in Debian. <...> The security team doesn't have the bandwidth to do it themselves, they need a team to help them. Sorry for a silly question, but whatʼs so wrong with the build done by linuxmint.com [1], so Debian needs a whole team to duplicate their effort? Itʼs for Debian 10 (i. e. oldstable) as of now, but works fine at Sid in my (limited) experience. Well, you can start with the fact that the Mint chromium source packages don't even include the chromium source, let alone the sources for all the other things they build (NodeJS, and more). The biggest difficulty, as far as I can tell from my look at Chromium from several months ago, is that our patch set [1] needs a lot of attention with every chromium release. Mint doesn't apply any patches at all to the source, at least none of any real complexity. One lesson we may take from Mint, though, is that it's not worth trying to patch Chromium as much as we'd like. Anything that we can do to simplify the Chromium packaging will help us keep the package up-to-date, which in turn will help us keep our users safer. In my opinion, we should be pretty aggressive about dropping as many of the Chromium patches as possible, even if that means we link against bundled/vendored dependencies. Legal/licensing considerations are still important and I don't know if we actually *can* ship builds based on the bundled stuff. But based on the number of patches we have to disable various things [2] or build against system dependencies [3], I can't help but think we'd have an easier time keeping this package fresh if we could drop some of those. noah 1. https://salsa.debian.org/chromium-team/chromium/-/blob/master/debian/patches/series 2. https://salsa.debian.org/chromium-team/chromium/-/tree/master/debian/patches/disable 3. https://salsa.debian.org/chromium-team/chromium/-/tree/master/debian/patches/system I'd also like to point out, that the ungoogled-chromium project has some overlap in goals with Debian and it'd possibly be interessing to join forces: https://github.com/ungoogled-software/ungoogled-chromium-debian (I have been running an ungoogled-chromium for a while (ca. a year ago?), however at that time their chrome wasn't extremely stable so I gave up again. Does anybody have experience using it recently?) *t
Re: Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)
On Tue, Dec 07, 2021 at 07:31:09PM +0100, Tomas Pospisek wrote: > > Obviously I cannot promise anything here; I'm currently even more in the > > dark > > than you. :-) But if there's a list of relevant bugs somewhere, I at least > > have a place to try to understand the issues at hand. The one bug I had in mind when I wrote my email was this: https://bugs.chromium.org/p/chromium/issues/detail?id=1250231 However I saw in the past also some cases of a bug reported, few versions later bug fixed, but actually the bug wasn't even touched, so most likely somebody else noticed "internally" but never saw the bug report. Besides that, look at the stupidly long list of patches. I consider it fair to say that for most of them chromium upstream could just trivially incorporate build flags or support our needs: none of those patches change foundamental behaviour or so. > PS: I have included Mattia Rizzolo, Michael Gilbert and the Debian Chromium > Team directly in the recipients, to be sure they see this email. I do hope > you all do not mind. That's all fine with me (also, I'm subscribed to d-d@ (and d-release@), but I'm not actually involved in the maintenance. Rather, I'm adding here Michel Le Bihan who actually maintained chromium in the past 8+ months, and I can only say that he did a great job, despite the short time. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Re: ungoogled-chromium?
* Tomas Pospisek: " ungoogled-chromium? [was: Re: Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)]" (Tue, 7 Dec 2021 19:43:10 +0100): > (I have been running an ungoogled-chromium for a while (ca. a year > ago?), however at that time their chrome wasn't extremely stable so I > gave up again. Does anybody have experience using it recently?) (Using chromium only as fallback browser if necessary): Since the removal of chromium from Debian was announced I gave UngoogledChromium on flatpak a try and it runs very stable so far. -- Mathias Behrle PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6 AC29 7E5C 46B9 D0B6 1C71 7681 D6D0 9BE4 8405 BBF6 pgpP9LgnNKfXL.pgp Description: Digitale Signatur von OpenPGP
Re: ungoogled-chromium?
❦ 7 December 2021 21:46 +01, Mathias Behrle: >> (I have been running an ungoogled-chromium for a while (ca. a year >> ago?), however at that time their chrome wasn't extremely stable so I >> gave up again. Does anybody have experience using it recently?) > > (Using chromium only as fallback browser if necessary): > > Since the removal of chromium from Debian was announced I gave > UngoogledChromium > on flatpak a try and it runs very stable so far. Same here. And they are now following security updates closely (in the past, there could lag two or three weeks behind). Flatpak compiles it from source (while UngoogledChromium let contributors compile it and publish the binary because GitHub CI does not allow such resource-heavy build). -- After all, all he did was string together a lot of old, well-known quotations. -- H. L. Mencken, on Shakespeare
Re: ungoogled-chromium?
On Tue, Dec 07, 2021 at 10:45:27PM +0100, Vincent Bernat wrote: > Same here. And they are now following security updates closely (in the > past, there could lag two or three weeks behind). Flatpak compiles it > from source (while UngoogledChromium let contributors compile it and > publish the binary because GitHub CI does not allow such resource-heavy > build). You mean th builds of the Flatpk stuff are not properly controlled? But instead uncontrolled done by contributors? Bastian -- There are some things worth dying for. -- Kirk, "Errand of Mercy", stardate 3201.7
Re: ungoogled-chromium?
On Tue, 07 Dec 2021 at 23:08:41 +0100, Bastian Blank wrote: > On Tue, Dec 07, 2021 at 10:45:27PM +0100, Vincent Bernat wrote: > > Flatpak compiles it > > from source (while UngoogledChromium let contributors compile it and > > publish the binary because GitHub CI does not allow such resource-heavy > > build). > > You mean th builds of the Flatpk stuff are not properly controlled? But > instead uncontrolled done by contributors? I think there is some confusion here. Flatpak is a piece of software (like apt/dpkg), not an organization or provider of compiled software (like Debian). Anyone can host a Flatpak repository, and you can deliver almost anything in Flatpak format (safe or not, Free or not, compiled from source or not), just like you can put almost anything in a .deb package. Flathub is a major build and distribution service for Flatpak apps, in the same way that Debian and Launchpad are major providers of .deb packages. Perhaps a closer parallel is that if Flatpak is like the Android app framework, then Flathub is like the Google Play store: you can use Flatpak without using Flathub at all, but most Flatpak users are using Flathub for at least some of their apps. If you think you have installed an app "from Flatpak" without any further details, it is probably from Flathub. Flathub generally requires builds to be done on Flathub's infrastructure, from source code if possible, in the same way Debian generally requires builds to be done on buildds, from source if possible. (Like Debian, it makes an exception for binary-only non-free software where no public source code is available.) At least one package on Flathub is built on third-party infrastructure and directly contributed as binaries even though it is open-source. The only example I'm aware of is Firefox, which is built by Mozilla's CI and provided to Flathub as binaries. I believe what Vincent meant is that the generic non-Flatpak binaries provided by the "Ungoogled Chromium" project are compiled on unknown machines and require trusting their submitters, whereas the Flatpak binaries provided by Flathub are compiled from the same source code provided by the "Ungoogled Chromium" project, but compiled on Flathub infrastructure. Here's an example of a build log from Flathub building Ungoogled Chromium, which does look like it came from source code (at least superficially, I haven't examined it in detail): https://flathub.org/builds/#/builders/12/builds/8123 It is possible that the "Ungoogled Chromium" Flatpak build on Flathub takes some parts as prebuilt binaries while compiling other parts from first principles. Someone would have to inspect the build in detail to find out, the same way it isn't trivial to tell from looking at a Debian package whether it is fully built-from-source or not. However, when a Flatpak app is compiled using flatpak-builder (which is what Flathub uses), the build is done in a sandbox that does not allow network access; so we can be sure that if the "Ungoogled Chromium" build contains prebuilt binaries, those prebuilt binaries must have been part of one of the "source" components listed in the JSON or YAML manifest that drives the build. This is similar to building a Debian package with `pbuilder build --network no` [1], and then being able to inspect the orig.tar.* and debian.tar.* to look for any prebuilt binaries that might have been used. smcv [1] but not sbuild (#802850): our policy forbids network access during build but our official infrastructure currently does not technically prevent it
Bug#1001304: ITP: golang-github-muesli-ansi -- raw ANSI sequence helpers for Go
Package: wnpp
Severity: wishlist
Owner: Anthony Fok
* Package name: golang-github-muesli-ansi
Version : 0.0~git20211031.c9f0611-1
Upstream Author : Christian Muehlhaeuser
* URL : https://github.com/muesli/ansi
* License : Expat
Programming Lang: Go
Description : raw ANSI sequence helpers for Go
Package ansi provides raw ANSI sequence helpers for Go.
.
ANSI Writer
.
import "github.com/muesli/ansi"
.
w := ansi.Writer{Forward: os.Stdout}
w.Write([]byte("\x1b[31mHello, world!\x1b[0m"))
w.Close()
.
Compressor
.
The ANSI compressor eliminates unnecessary/redundant ANSI sequences.
.
import "github.com/muesli/ansi/compressor"
.
w := compressor.Writer{Forward: os.Stdout}
w.Write([]byte("\x1b[31mHello, world!\x1b[0m"))
w.Close()
Reason for packaging:
Prerequisite for golang-github-charmbracelet-bubbletea
@ https://github.com/charmbracelet/bubbletea
Re: ungoogled-chromium?
On Tue, 2021-12-07 at 23:35 +, Simon McVittie wrote: > Flathub generally requires builds to be done on Flathub's > infrastructure, from source code if possible, in the same way Debian > generally requires builds to be done on buildds, from source if > possible. Are you sure about that? Is there a policy? > At least one package on Flathub is built on third-party > infrastructure > and directly contributed as binaries even though it is open-source. > The only example I'm aware of is Firefox, which is built by > Mozilla's CI and provided to Flathub as binaries. The Flatpak package for the Signal desktop app is literally built by downloading and unpacking the binary deb from the vendor. https://github.com/flathub/org.signal.Signal/blob/master/org.signal.Signal.json Signal itself is open source, but the build process is a complex NPM rabbit hole. Regards
Bug#1001310: ITP: golang-github-charmbracelet-lipgloss -- style definitions for nice terminal layouts
Package: wnpp Severity: wishlist Owner: Anthony Fok * Package name: golang-github-charmbracelet-lipgloss Version : 0.4.0-1 Upstream Author : Charm * URL : https://github.com/charmbracelet/lipgloss * License : Expat Programming Lang: Go Description : style definitions for nice terminal layouts 👄 Go package lipgloss provides style definitions for nice terminal layouts. Built with TUIs in mind. . Lip Gloss takes an expressive, declarative approach to terminal rendering. Users familiar with CSS will feel at home with Lip Gloss. Reason for packaging: Prerequsite for e.g. github.com/muesli/gitty
Re: ungoogled-chromium?
❦ 7 December 2021 23:35 GMT, Simon McVittie: > I believe what Vincent meant is that the generic non-Flatpak binaries > provided by the "Ungoogled Chromium" project are compiled on unknown > machines and require trusting their submitters, whereas the Flatpak > binaries provided by Flathub are compiled from the same source > code provided by the "Ungoogled Chromium" project, but compiled on > Flathub infrastructure. Yes. -- Don't stop with your first draft. - The Elements of Programming Style (Kernighan & Plauger)
