Re: xz backdoor

Russ Allbery wrote: > I think this question can only be answered with reverse-engineering of the > backdoors, and I personally don't have the skills to do that. In the pre-disclosure discussion permission was asked to share the payload with a company specialising in such reverse engineering. If

Enabling -fstack-clash-protection for trixie

Following the procedure to modify default dpkg-buildflags I propose to enable -fstack-clash-protection on amd64. The bug for dpkg tracking this is #918914. | -fstack-clash-protection | Generate code to prevent stack clash style attacks. When this option | is enabled, the compiler will only

Re: Enabling branch protection on amd64 and arm64

Am Wed, Jun 21, 2023 at 05:41:36PM +0200 schrieb Emanuele Rocca: > Hey Moritz, > > On 2022-10-26 08:20, Moritz Mühlenhoff wrote: > > I think this should rather be applied early after the Bookworm > > release (and ideally we can also finish off the necessary testing >

Re: Enabling branch protection on amd64 and arm64

Wookey wrote: > So the immediate issue now is whether or not to enable this by default > in bookworm? The majority of packages will not be rebuilt until the release, so if we add this now it means that packages pick up the change when they are rebuilt in stable via a security update or point

Re: Bug#1013132: ITP: BabaSSL -- BabaSSL is a base library for modern cryptography and communication security protocols.

Stephan Verbücheln schrieb: > As far as I understand it, the main point of BabaSSL is to add support > for Chinese developed ciphers and algorithms. One alternative would be to ship those ciphers as a module for OpenSSL, this already happens with the Russian GOST ciphers via the

Re: Bug#1013132: ITP: BabaSSL -- BabaSSL is a base library for modern cryptography and communication security protocols.

Am Wed, Jun 22, 2022 at 02:28:36PM + schrieb Lance Lin: > Hello Marco, > > > What is the plan? Are there any current or new packages which will > > depend on it? > > Yes, from my understanding it is a "drop in" replacement for OpenSSL. One of > my packages (Workflow) uses it but can also

Re: Firmware - what are we going to do about it?

Steve McIntyre wrote: > What would I choose to do? My personal preference would be to go with optiob > 5: > split the non-free firmware into a special new component and include that on > official media. I fully agree with that (as mentioned before when the discussion came up). I also believe we

Re: The future of src:ntp

Bernhard Schmidt wrote: > However, development for ntp.org is slow, upstream still using BitKeeper > is cumbersome, and even the testsuite needs to be fixes on some > architectures for new releases. Both ntpsec and chrony are (from my POV) > the better alternatives now. To a point where I

Dropping dpatch for bookworm

There are only 24 packages left using dpatch and the vast majority of remaining uses are packages which haven't seen a maintainer upload for a decade or longer. Some of these have existing "please migrate to source format 3(quilt)" bugs already and in the interest of more streamlined packaging

Re: chromium: Update to version 94.0.4606.61 (security-fixes)

Am Sun, Dec 05, 2021 at 10:53:56AM +0100 schrieb Paul Gevers: > Hi Andres, > > On 05-12-2021 03:36, Andres Salomon 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

Re: MBF: please drop transitional dummy package foo (if they were part of two releases or more)

Holger Levsen wrote: > again, I'm planning an small mass bug filing against obsolete transitional > packages, which are at least marked "dummy transitional" since the buster > release, Thanks for taking care of this! But I'm wondering if this wouldn't be a perfect task for a Debian Janitor

Re: Steam Deck: good news for Linux gaming, bad news for Debian :(

Jonathan Dowland schrieb: >> Amarok was removed as it required the obsolete Qt 4 library. Now that >> upstream has finally ported it to Qt5, it could be reintroduced to >> Debian. > > That's an interesting way of presenting the situation. Amarok was > removed because we aggressively removed Qt4,

Re: Backports needed for Firefox/Thunderbird ESR 78 in Buster/Stretch

[Adding debian-devel to the list] On Sun, Aug 02, 2020 at 06:21:30PM +0200, Moritz Mühlenhoff wrote: > > We are at this point again. ESR 68 will be EOL on September 22nd, when 78.3 > > comes out. We have some time still, but if we want FF and TB to keep being > > supported, we'

Re: NMU for Imagemagick?

Jonathan Carter schrieb: > Hi > > Imagemagick in Debian is extremely outdated (6.9.10.23 vs 7.0.10-21), > causing some FTBFS on packages that depend on it. > > I know this package is notorious for needing security updates, and not > sure if there might be a good reason for it to be stuck on it's

Re: Salsa update: no more "-guest" and more

Russ Allbery schrieb: > Vincent Bernat writes: > >> This is not how this is implemented. I am using GitHub and GitLab with >> 2FA enabled and I am rarely asked to enter any token. Once you get >> authenticated on a device, it remains for a long time. > > Pretty much every time I go to

Re: What to do when DD considers policy to be optional? [kubernetes]

Russ Allbery schrieb: > Michael Lustfield writes: > >> One last thing to consider... NEW reviews are already an intense >> process. If this package hit NEW /and/ we allowed vendored libs, you >> could safely expect me to never complete that particular review. I doubt >> I'm the only one; that's

Re: new kubernetes packaging

Sean Whitton wrote: > I am not sure, however, that your argument applies to security updates > to our stable releases. These updates are almost always a matter of > backporting small fixes, rather than updating to new upstream releases. > And for backported fixes, vendoring makes things much

Re: [Pkg-puppet-devel] Dependencies on obsolete puppet-common transitional package (potential mass bug filing).

Thomas Goirand wrote: > Gosh, these are all mine... Don't worry, no need to bother filling bugs, > I'll take care of it. However, what package should it depends on now? On "puppet". Cheers, Moritz

Re: Kernel parameters protecting fifos and regular files

Craig Small schrieb: > --4806c5059d3edeb1 > Content-Type: text/plain; charset="UTF-8" > > Hi, > About 2 years ago the procps package added protection for hard and soft > symlinks. The bug report was 889098 and has seemed to work fine. > > There is also now bug #914859 which would

Re: Automated removal of RC buggy packages

On Mon, Nov 11, 2019 at 06:00:18PM -0500, Sam Hartman wrote: > Moritz> We should even work towards automating this further; if a > Moritz> package is RC-buggy for longer than say a year (with some > Moritz> select exceptions) it should just get auto-removed from the > Moritz>

Re: Python 2 removal in sid/bullseye: Progress and next steps

Scott Kitterman schrieb: > One maintainer doesn't get to block the removal of an entire stack like Qt4. > I think there's a reasonable point of discussion about when RoQA is > appropriate, but there comes a time when stuff just has to go. > That doesn't make it a free for all, but for old,

Re: BITS from the DPL For September/October 2019

Thomas Goirand schrieb: > "I’d very happily maintain the init script." > > I haven't read all the bug entry, but if someone is claiming that > accepting such contribution is mandatory, then that's very much right, > at least that the consensus we're in right now, indeed. This isn't limited to

Re: BITS from the DPL For September/October 2019

Thomas Goirand schrieb: > My understanding is that the current guidance is that doing init script > isn't mandatory. With policy not updated, people claim it's mandatory, see e.g. #925473 on Tomcat. The discussed GRs would provide clarification on what the project at large actually wants (and

Re: should all bug reports be filed against /source/ packages?

Ansgar schrieb: > the thread about naming (source) packages reminded me of an other thing: > Debian's bug tracking system currently (mostly) tracks bugs against > binary packages and (less often) against source packages. > > It gets confused if a source & binary package with the same name, but >

Re: Backports needed for Firefox/Thunderbird ESR 68 in Stretch

On Tue, Jul 02, 2019 at 10:45:20PM +0200, Moritz Mühlenhoff wrote: > Hi, > Firefox 68 will be the next ESR release series. With the release of Firefox > 68.2 > on October 22nd, support for ESR 60 will cease. > > ESR 68 will require an updated Rust/Cargo toolchain and

Re: The noudeb build profile and dh-only rules files

Theodore Ts'o schrieb: > Back in the days of boot/root installation floppies, saving every last > byte was clearly important. It's probably worth discussing/investigating whether udebs in general still make sense for d-i in 2019? It was a design choice made 15 years ago, but disk/network

Backports needed for Firefox/Thunderbird ESR 68 in Stretch

Hi, Firefox 68 will be the next ESR release series. With the release of Firefox 68.2 on October 22nd, support for ESR 60 will cease. ESR 68 will require an updated Rust/Cargo toolchain and build dependencies not present in Stretch (nodejs 8, llvm-toolchain-7, cbindgen and maybe more). Stretch was

Re: AMDGPU+OpenCL with Debian?

Michael Kesper schrieb: > On 18.06.19 22:55, Moritz M=C3=BChlenhoff wrote: >> You may find https://phabricator.wikimedia.org/T148843/#5078403 >> (and later) interesting,=20 > > This seems to require wikimedia authentication. > Is there some information publicly available about it? Ah, that's

Re: AMDGPU+OpenCL with Debian?

Mo Zhou schrieb: > On 2019-06-18 03:15, PICCA Frederic-Emmanuel wrote: >> Same here... with WXX100 cards. >> what about rocm packaging ? > > Not easy. Involves a toolchain. > Is ROCm promising enough to challenge CUDA? > (Although ROCm has already beaten CUDA in > terms of license). You may find

Re: binutils security support (Re: fixing debian-security-support upgrades from stretch (for good))

Holger Levsen schrieb: > (and yes, I also agree this is quite a desaster, just like > kde4libs/khtml only is suitable for trusted content, which IOW means, > one should not use konqueror or kmail on the interweb.) That is the upstream status quo and not in any way specific to Debian, we're just

Re: Do we want to Require or Recommend DH

Simon McVittie schrieb: > Packages using dh also make it a lot more straightforward to do > archive-wide changes - similar to the benefit of using debhelper, but > for changes that affect the "shape" of the build system rather than the > details of individual steps. As a concrete example, Or

Re: Proposal: Repository for fast-paced package backports

Thomas Goirand schrieb: > And for a start, I don't think you really need a buildd network, just amd64 > is ok-ish. Agreed. If there's actual demand for further architecture support, it will appear naturally by people offering to do the necessary setup. Cheers, Moritz

Re: Uncoordinated upload of the rustified librsvg

Seth Arnold schrieb: > It doesn't help that the distributions in general want to support Firefox > on more platforms than the Rust team supports as tier-1 platforms. A > constant cadence of updates every six weeks is faster than anything else > excepting the Linux kernel. It's a lot of work. Why

Re: Firefox 60esr on Stretch ?

Hideki Yamane schrieb: > Hi, > > On Fri, 18 May 2018 10:29:03 +0200 > Moritz Mühlenhoff wrote: >> > Does it fail like in bug #858153 (which has a patch) or in a different way? >> >> That bug is a year old and for 0.19, not sure if it's still any relevant >

Re: Firefox 60esr on Stretch ?

Emilio Pozuelo Monfort <po...@debian.org> schrieb: > On 16/05/18 19:12, Moritz Mühlenhoff wrote: >> I've started to look into this; I have created a llvm-4.0 build >> for stretch and build a bootstrap build of rustc 1.24 against it. >> Those two went fine. >&

Re: Firefox 60esr on Stretch ?

Hideki Yamane schrieb: > Firefox60 needs rustc (>= 1.24) to be built but rustc in stretch is 1.14. > rustc (>= 1.24) needs llvm-4.0 and cargo but it is not in stretch... > > - add llvm-4.0 and cargo to stretch > - backport rustc > - rebuild build-depends: rustc

Re: Firefox 60esr on Stretch ?

W. Martin Borgert <deba...@debian.org> schrieb: > On 2018-05-04 21:12, Moritz Mühlenhoff wrote: >> Same as all previous extension breakages incurred by ESR transitions; >> not at all. Apart from enigmail those are all not updated along >> in stable, this doesn't sca

Re: Firefox 60esr on Stretch ?

W. Martin Borgert <deba...@debian.org> schrieb: > Quoting Moritz Mühlenhoff <j...@inutil.org>: >> Julien Cristau <jcris...@debian.org> schrieb: >>> I expect nothing much different from previous ESR cycles: stretch will >>> move to 60 after 52 goes EOL

Re: Firefox 60esr on Stretch ?

Julien Cristau schrieb: > I expect nothing much different from previous ESR cycles: stretch will > move to 60 after 52 goes EOL in September. Exactly. Cheers, Moritz

Re: Extended Long Term Support for Wheezy

On Thu, Feb 22, 2018 at 02:57:07PM +0100, Raphael Hertzog wrote: > But assuming that we keep updates hosted on some debian.org host, do you > think it's OK to continue to use the security tracker to track > vulnerabilities in wheezy? Need to be discussed with the rest of the team, I'm not really

Re: Extended Long Term Support for Wheezy

Raphael Hertzog wrote: > some of the LTS sponsors are looking to extend the support period of > Debian 7 Wheezy (from a few months up to a full year). > > Our question is whether this can be done on debian.org infrastructure. LTS has a clearly defined scope, while this is essentially contracting

Re: What can Debian do to provide complex applications to its users?

Raphael Hertzog schrieb: > What do you think? Do you have other ideas? Are there other persons > who are annoyed by the current situation? There's clearly a set of software which is of high quality, but where upstream's development practices are not usefully aligned with our

Re: Compiler with Spectre mitigation retpoline/-mindirect-branch=thunk

Robin Geuze schrieb: > I was wondering, are the debian maintainers planning on backporting the > -mindirect-branch=thunk support introduced in GCC 7.3 and 8.1 to the > compilers available on Jessie and Stretch? While this is not necessarily > a security fix for the compiler

Re: Compiler with Spectre mitigation retpoline/-mindirect-branch=thunk

Philipp Hahn wrote: > PS: Here are the 7 relevant GIT commpits for gcc-4.9 from H.J. Lu's GIT > repository for reference: >> 1fb3a1828fa x86: Disallow -mindirect-branch=/-mfunction-return= with >> -mcmodel=large >> 7ab5b649f72 x86: Add 'V' register operand modifier >> 5550079949a x86: Add

Re: Bug#754513: RFP: libressl -- SSL library, forked from OpenSSL

Colin Watson schrieb: > While there does exist a skeletal compatibility layer linked from the > upstream wiki [1], the OpenSSL developers explicitly don't want to > maintain this properly [2], and the OpenSSH developers say that it is > "unversioned, incomplete, barely

Re: OpenSSL disables TLS 1.0 and 1.1

Marco d'Itri schrieb: >> The only thing you would achieve would be to force people to move >> away from Debian to distributions that are still able to interact >> with devices running ancient and highly insecure Android firmwares. > +1 I agree it's not something that should end up

Re: Let's enable AppArmor by default (why not?)

Christian Seiler schrieb: > Another thing to consider: if a profile is too restrictive, but the > part that is too restrictive isn't in the upstream kernel yet, then > things could break if you upgrade the kernel to a newer version from > e.g. backports later on. How would you

Re: Let's enable AppArmor by default (why not?)

intrigeri schrieb: > Still, even with the set of features available in mainline Linux > *today*, IMO enabling AppArmor already has a good cost/benefit ratio > for Debian and our users. I'm not proposing we apply out-of-tree > AppArmor kernel patches. I'd expect that a lot

Re: Mitigating the problem of limited security support

Alberto Garcia wrote: > The problem is that point releases with fixes for CVEs can also > introduce regressions (#855103, introduced in 2.14.4). That one was > fixed quickly, though, but that's why I was asking. The security archive doesn't scale to play catchup with all those rdeps. There's too

Re: Mitigating the problem of limited security support

Jeremy Bicha schrieb: > understanding is that the Debian Security team has absolutely refused > to extend the "browser exception" (to allow major new versions) to > webkit2gtk, The "browser exception" applies to Chromium and Firefox, which are standalone packages (sans a few

Re: System libraries and the GPLv2 (was: Re: GnuTLS in Debian)

Florian Weimer schrieb: > Would it be possible to get real legal advice on this matter, with the > concrete goal to find a usable process to leverage the system library > exception in the GPLv2? We should have done that a decade ago... The SFLC can probably help, but an

Re: OpenSSL 1.1.0

Adrian Bunk schrieb: > Supporting 1.0.2 only [1] plus chacha20 patched into that - it is not > obvious to me why this would be that much worse in comparison that > it would not be an option under any circumstances. That patch has never been upstreamed and is not something we can

Re: OpenSSL 1.1.0

Stefan Fritsch <s...@sfritsch.de> schrieb: > On Friday, 18 November 2016 22:22:59 CET Moritz Mühlenhoff wrote: >> Adrian Bunk <b...@stusta.de> schrieb: >> > And/or get sponsorship from companies for supporting ChaCha20-patched >> > 1.0.2 >> >> It

Re: OpenSSL 1.1.0

Adrian Bunk schrieb: > And/or get sponsorship from companies for supporting ChaCha20-patched > 1.0.2 It's not a matter of whipping up some patch; anything less than an official backport of chacha20 into a 1.0.2x release is not going to be supportable. Cheers, Moritz

Re: OpenSSL 1.1.0

Adrian Bunk schrieb: > On Tue, Nov 15, 2016 at 09:37:01AM -0300, Lisandro Damián Nicanor Pérez Meyer > wrote: >> On lunes, 14 de noviembre de 2016 16:51:04 ART Marco d'Itri wrote: >> > On Nov 14, Lisandro Damián Nicanor Pérez Meyer >> > wrote: >> > > And

Re: OpenSSL 1.1.0

Stephan Seitz wrote: > And there is still the problem that 1.1.0 is not supported as long as the > available LTS version. That's not a decisive factor, Debian security support has been extended over the upstream support time frame many times before. Cheers, Moritz

Re: unattended-upgrades by default?

Steve McIntyre schrieb: > Definitely. I think we've got general consenus here, and we should do > the following: > > * work on fixing some of the highlighted bugs in unattended-upgrades > > * enable it for installation via d-i by default. At installation >time, it should

Re: Standards-Version field should be deprecated

Josh Triplett schrieb: > I do see value in documenting the version of Policy a package complies > with. However, I can also imagine some approaches to eliminate the > busywork. We could reduce the policy checklist to issues not covered/coverable by Lintian tests (which

Re: copyright precision

Simon McVittie schrieb: > In particular, if this thread comes to the conclusion that more needs to > be done than what maintainers currently do, then it should be something > actionable; Or we could rather automate the generation of debian/copyright entirely by letting fossology

Re: OpenSSL 1.1.0

Jérémy Lal wrote > The openssl release strategy page [1] states: > Version 1.1.0 will be supported until 2018-04-30. > Version 1.0.2 will be supported until 2019-12-31 (LTS). > > Considering the dates, upstream authors using openssl 1.0.2 might not > migrate to the new api

Re: Question about flashplugin-nonfree

Marcio Souza wrote: > The problem is that most Debian users to update the system using apt-get > update && apt-get upgrade or the like. > Thus the flash plugin is not updated and the security problem will persist. > > I believe that the flash update should be automatic

Re: GNU IceCat?

Russ Allbery schrieb: > Simon Josefsson writes: > >> Is there any reason (other than lack of manpower) that GNU IceCat is not >> packaged in Debian? > > I suspect it's mostly just resources, but it's an immense amount of work, > and not just for the

Re: The Spirit of Free Software, or The Reality

Paul Wise p...@debian.org schrieb: On Thu, Jul 16, 2015 at 6:17 AM, Mike Hommey wrote: I, myself, find our DFSG-freeness pickiness going too far, and I'm sick of this icon thing. So, here's what I'm going to do: unless I hear non-IANAL objection until the next upstream release due on august

Re: Debian LSB compliance

Didier 'OdyX' Raboud o...@debian.org wrote: Given a) the work that certifying Debian would take; b) the interest in having Debian be certified (I am yet to see any of that interest); c) the marginal interest by application vendors for the LSB; I'm leaning towards outright giving up.

Re: Bug#771099: ITP: cakephp2 -- MVC rapid application development framework for PHP (2.x series)

Maxime Chatelle x...@rxsoft.eu schrieb: Package: wnpp Severity: wishlist Owner: Maxime Chatelle x...@rxsoft.eu * Package name: cakephp2 Version : 2.5.6 Upstream Author : http://cakefoundation.org/ * URL : http://cakephp.org/ * License : MIT

Re: Reintroducing FFmpeg to Debian

Andreas Cadhalpun andreas.cadhal...@googlemail.com schrieb: Hi Thomas, On 18.08.2014 08:36, Thomas Goirand wrote: There's been a very well commented technical reason stated here: the release team don't want to deal with 2 of the same library that are doing (nearly) the same things, with

Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian

Wookey woo...@wookware.org schrieb: Unless we were to decide to make an exception re internal libraries (which seems unlikely in this case given the general discussion on security load), this package is not going to make it into Debian anytime soon, which from my POV is very sad - I had

Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian

Josselin Mouette j...@debian.org schrieb: Le jeudi 31 juillet 2014 à 22:19 +0200, Pau Garcia i Quiles a écrit : How is it better to have libav, which does a lot less security bugfixing, in? I'd rather have a library that fixes bugs than one that passes in order to look more secure. When in

Re: Why not 03 ?

Charles Plessy ple...@debian.org schrieb: Perhaps we can stop overriding this option ? For a lot of scientific packages, -O3 is chosen by the upstream author, and I always feel bad that if we make the programs slower by overriding it to -O2, it will reflect poorly on Debian as a distribution

Re: Bits from the Security Team

Christoph Biedl debian.a...@manchmal.in-ulm.de schrieb: Matthias Urlichs wrote... IMHO the decision to designate release N to be a LTS release has too be made at release time of N+1 _at_the_latest_, so maintainers know that they may not remove their old upgrade script snippets. Agreed, but

Re: Bits from the Security Team

On Thu, Mar 06, 2014 at 09:00:13AM +0800, Paul Wise wrote: * There are quite some vulnerabilities which are addressed in Debian, but for which no CVE identifier has been assigned. Perhaps we could encourage those submitting security bugs to X-Debbugs-CC the oss-sec list? That would

Re: FFmpeg vs. libav packaging

Jonathan Dowland j...@debian.org schrieb: Moritz, what's the security team's opinion on ffmpeg being reintroduced as a binary package (providing /usr/bin/ffmpeg) only? Doesn't make much of a difference, since it still exposes all the same decoders and demuxers through the ffmpeg binary.

Re: FFmpeg vs. libav packaging

Russ Allbery r...@debian.org schrieb: Paul Wise p...@debian.org writes: On Fri, Feb 14, 2014 at 5:40 AM, Adrian Bunk wrote: Having both sets of libraries in the archive at the same time is what I called insane in the RFP and where I expect additional probems due to: Also, I expect the

Re: lcms - lcms2 migration

On Sun, Dec 29, 2013 at 11:25:48AM +0100, Bastien ROUCARIES wrote: On Sun, Dec 29, 2013 at 10:33 AM, Moritz Mühlenhoff j...@inutil.org wrote: Hi, lcms needs to go for jessie in favour of lcms2 (#717928). (liblcms1-dev - liblcms2-dev) The maintainer seems MIA, so I'm going ahead. Below

Re: Proposal: remove krb5-appl (rlogin, rsh, telnet, ftp with krb5 support)

Brian May br...@microcomaustralia.com.au schrieb: --001a11c1fd62df72e504f0aac077 Content-Type: text/plain; charset=UTF-8 On 24 January 2014 04:14, Jelmer Vernooij jel...@samba.org wrote: My proposal is to drop the package from the archive, but I wanted to give others a chance to shout out

Upcoming switch to ESR24 for iceweasel in stable-security

Hi, quick heads up for everyone maintaining xul-ext-* packages: We'll soon update iceweasel in stable-security to the ESR24 branch, test packages can be fetched from http://mozilla.debian.net/24/ Cheers, Moritz -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a

Re: GnuTLS in Debian

Andreas Metzler ametz...@debian.org schrieb: #5 Declare GMP to be a system library. (..) #5 was how Fedora looked at the OpenSSL library issue. Since Debian has another viewpoint on OpenSSL I somehow doubt we would use it for GMP. We should do that (and also reevaluate the position wrt

Re: Bug#732159: Should this package be removed?

Ian Jackson ijack...@chiark.greenend.org.uk schrieb: Jonas: Is your view that the packages which aren't working properly with libav (including mplayer) should be removed from Debian ? mplayer doesn't need to be removed because of any compatibility issues with libav. It FTBFSes for entirely

Re: Bug#732159: Should this package be removed?

Bálint Réczey bal...@balintreczey.hu schrieb: How about introducing the ffmpeg shared libraries with libffmpeg prefix instead of libav prefix? No way. Keeping up with security fixes for libav is tedious enough, we cannot reasonably have both. Cheers, Moritz -- To UNSUBSCRIBE, email

Accepted open-vm-tools 2:9.2.3-1031360-7 (source amd64 all)

-1031360-7 Distribution: unstable Urgency: low Maintainer: Debian QA Group packa...@qa.debian.org Changed-By: Moritz Mühlenhoff muehlenh...@univention.de Description: open-vm-dkms - Open VMware Tools for virtual machines hosted on VMware (transiti open-vm-toolbox - Open VMware Tools for virtual

Re: to those who want to support Debian longer...

Holger Levsen hol...@layer-acht.org schrieb: please start with helping supporting the current stable release better: Indeed, actions speak louder than words. Here's four specific packages, where the security team could need some help for an oldstable-security update: - mysql-5.1 needs to be

Re: Dreamhost dumps Debian

Russ Allbery r...@debian.org schrieb: Pau Garcia i Quiles pgqui...@elpauer.org writes: On Tue, Aug 20, 2013 at 8:25 PM, Russ Allbery r...@debian.org wrote: My experience is that I can just barely manage to convince upstreams to look over my backports of security patches to packages in

Re: Dreamhost dumps Debian

Steve Langasek vor...@debian.org schrieb: I understand the motivation (like everyone else they have more to do than they have time to do it in), but I think the outcome, whereby the security team denies use of the security update channel for non-critical security bugs and redirects

Re: Longer maintainance for (former) stable releases of Debian (Re: Dreamhost dumps Debian)

Michael Meskes mes...@debian.org schrieb: Which brings up the interesting question how it works for stable now. How often do bigs get fixed by the security team and how often by maintainers themselves? No hard numbers, but I'd suppose half and half (i.e. cases, where the maintainer prepared

Re: Survey answers part 3: systemd is not portable and what this means for our ports

John Paul Adrian Glaubitz glaub...@physik.fu-berlin.de schrieb: On 07/13/2013 11:46 PM, Michael Stapelberg wrote: since some people might not read planet debian, here is a link to my third blog post in a series of posts dealing with the results of the Debian systemd survey:

Re: Reporting 1.2K crashes

Alexandre Rebert alexandre.reb...@gmail.com schrieb: Hi, I am a security researcher at Carnegie Mellon University, and my team has found thousands of crashes in binaries downloaded from debian wheeze packages. After contacting ow...@bugs.debian.org, Don Armstrong advised us to contact you

Re: Switching to mozilla ESR in stable-security

Christoph Anton Mitterer cales...@scientia.net schrieb: --=-dGSWlplfgLb+HUgDia6J Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Moritz. Moritz Muehlenhoff wrote: In the future the majority of packages should thus rather be installed through

Re: Switching to mozilla ESR in stable-security

Didier 'OdyX' Raboud o...@debian.org schrieb: FWIW, I don't. I think the compromise that the security team is proposing is much more reasonable than such an alternative. That compromise (which I do definitely support for wheezy) puzzles me most for the precedent it creates: if we give up

Re: Switching to mozilla ESR in stable-security

Ansgar Burchardt ans...@debian.org schrieb: Hi, On 05/28/2013 22:33, Moritz Muehlenhoff wrote: As such, we'll switch to releasing the ESR releases of iceweasel and icedove in stable-security. Reverse-deps of the older xulrunner libs have negligable security impact and we won't update them

Re: Switching to mozilla ESR in stable-security

Andrei POPESCU andreimpope...@gmail.com schrieb: --Yvzb+MHGXtbPBi5F Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Ma, 28 mai 13, 22:33:03, Moritz Muehlenhoff wrote: =20 As such, we'll switch to releasing the ESR

Re: Switching to mozilla ESR in stable-security

Arno Töll a...@debian.org schrieb: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --enigD8B4E48BF27B74A11F1ECB8F Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 29.05.2013 15:15, Ansgar Burchardt wrote: I would expect some

Re: Switching to mozilla ESR in stable-security

Willi Mann foss...@wm1.at schrieb: Hello Moritz, Moritz Muehlenhoff wrote: As such, we'll switch to releasing the ESR releases of iceweasel and icedove in stable-security. wouldn't it be better to do the bumps of major ESR versions in point releases? That might also allow a few more

Re: Bug#666490: O: svgalib -- console SVGA display libraries

On Mon, May 13, 2013 at 07:30:20PM +0200, Stephen Kitt wrote: Hi, On Sun, Apr 01, 2012 at 02:59:24AM +0100, Ben Hutchings wrote: Thanks for your work, but isn't it time we quietly got rid of this library? Video memory and mode setting should be managed by the kernel, not by

Re: jessie release goals

Christoph Biedl debian.a...@manchmal.in-ulm.de schrieb: Another thing: Hardening already has been a release goal but there still are packages around without. Agreed. I made a concentrated effort for Wheezy by submitting lots of patches for crucial packages and the general adoption among

Accepted elinks 0.12~pre5-9 (source amd64 all)

...@debian.org Changed-By: Moritz Mühlenhoff j...@debian.org Description: elinks - advanced text-mode WWW browser elinks-data - advanced text-mode WWW browser - data files elinks-doc - advanced text-mode WWW browser - documentation elinks-lite - advanced text-mode WWW browser - lightweight version

Re: Bug#672695: wordpress: no sane way for security updates in stable releases

On Sun, May 13, 2012 at 02:54:40PM +0200, Yves-Alexis Perez wrote: On sam., 2012-05-12 at 23:45 +0200, Bernd Zeimetz wrote: Being forced to upgrade to a new major version by a stable security support is nothing we should force our users to. Debian stable is known for (usually) painfree

Re: Please make yourself maintainer

retitle 548366 O: irdc-hybrid -- high-performance secure IRC server reassign 548366 wpp thanks On Fri, Sep 25, 2009 at 01:11:32PM -0700, Joshua Kwan wrote: Package: ircd-hybrid Hi Aurelien, Please feel free to remove me as Maintainer and take it on as your own package. I haven't worked on

Re: Enabling hardened build flags for Wheezy

Charles Plessy ple...@debian.org schrieb: Le Wed, Feb 29, 2012 at 10:52:10PM +0100, Moritz Muehlenhoff a écrit : -BEGIN PGP SIGNED MESSAGE- Since it will be almost impossible to convert all packages before Wheezy freezes, a specific sub-group of packages receives targeted

Re: Enabling hardened build flags for Wheezy

Nikolaus Rath nikol...@rath.org schrieb: Moritz Muehlenhoff j...@debian.org writes: Hi, dpkg-buildflags allows a uniform setting of default build flags for code written in C and C++. Using dpkg-build-flags in your rules files has a number of benefits: [...] Should packages of Python

Re: Enabling hardened build flags for Wheezy

Russ Allbery r...@debian.org schrieb: Paul Wise p...@debian.org writes: Personally I think this is completely the wrong approach to take for compiler hardening flags. The flags should be enabled by default in upstream GCC and disabled by upstream software where they result in problems. If

  1   2   >