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 t
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 allocat
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
>
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 relea
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
libengine-gost-op
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 use
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 c
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 would
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 wo
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
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 fix
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, d
[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&
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 c
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 salsa.debia
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 e
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 hard
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
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 ext
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> archiv
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, unsuppo
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 jus
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 wh
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
> o
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 buil
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 constra
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
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 just
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
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 t
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 e.g.
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
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
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
&
Emilio Pozuelo Monfort 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.
>>
>> However carg
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 packages?
> - firefox-esr 60 t
W. Martin Borgert 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 scale at all. If you want you
W. Martin Borgert schrieb:
> Quoting Moritz Mühlenhoff :
>> Julien Cristau schrieb:
>>> I expect nothing much different from previous ESR cycles: stretch will
>>> move to 60 after 52 goes EOL in September.
>>
>> Exactly.
>
> How will we deal wi
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
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
e
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
w
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
existing distro model
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 it does provide that
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 -mindire
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 documented, and seems to be
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 in a stable rel
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 deal with that kind
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 of the AppArmor profiles
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 m
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 addons breaking), but
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 official request to them
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
rely on, it's al
Stefan Fritsch schrieb:
> On Friday, 18 November 2016 22:22:59 CET Moritz Mühlenhoff wrote:
>> 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
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
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 yes, I would step back and switch libssl
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
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 be enabled by defaul
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 should be a rather small s
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 detect all the co
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 until 1.0.2 end of life.
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 because no update
> is a sec
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 packaging. Web browsers have one of the larges
Paul Wise 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 11
>> (an
Didier 'OdyX' Raboud 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.
Agreed, spen
Maxime Chatelle schrieb:
> Package: wnpp
> Severity: wishlist
> Owner: Maxime Chatelle
>
> * Package name: cakephp2
> Version : 2.5.6
> Upstream Author : http://cakefoundation.org/
> * URL : http://cakephp.org/
> * License : MIT
> Programming Lang: PHP
> De
Andreas Cadhalpun 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 potentially the same securit
Wookey 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 thought we were
> clos
Josselin Mouette 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 fact
Charles Plessy 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 for scientific
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 woul
Christoph Biedl 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 given the long inte
Jonathan Dowland 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.
Cheers,
Mori
Russ Allbery schrieb:
> Paul Wise 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 security team wou
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 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 is a dd
Brian May schrieb:
> --001a11c1fd62df72e504f0aac077
> Content-Type: text/plain; charset=UTF-8
>
> On 24 January 2014 04:14, Jelmer Vernooij wrote:
>
>> > My proposal is to drop the package from the archive, but I wanted to
>> > give others a chance to shout out that I'm wrong and that there's som
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 s
Andreas Metzler 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 OpenSSL) by
running
Ian Jackson 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 unrelated reasons since 9 months (
Bálint Réczey 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 to debian-devel-requ
Holger Levsen 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 updated to 5.1.71
- Seve
Michael Meskes 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 the update, w
Steve Langasek 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
> maintainers to stable
Russ Allbery schrieb:
> Pau Garcia i Quiles writes:
>> On Tue, Aug 20, 2013 at 8:25 PM, Russ Allbery wrote:
>
>>> My experience is that I can just barely manage to convince upstreams to
>>> look over my backports of security patches to packages in oldstable
>
>> What makes you think Ubuntu, Red
John Paul Adrian Glaubitz 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:
>>
>> http://people.debian.org/~stapelber
Alexandre Rebert 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 before submitting ~1.2K
Andrei POPESCU 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 releases of icewease
Ansgar Burchardt 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 any fur
Didier 'OdyX' Raboud 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" [0] mai
Christoph Anton Mitterer 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 http://addons.m
Willi Mann 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 extensions
Arno Töll 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 more pac
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 appl
Christoph Biedl 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 maintainers
is increasing. Also, Sim
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)
> > pa
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 work
Charles Plessy 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
>> attention:
>>
>
Kees Cook schrieb:
> In the mean time, I'll continue to work on the crappy
> heuristic checks. ;)
Shall we move hardening-check to devscripts, now that
dpkg-buildflags slowly trickles into standard Debian
development practice?
Cheers,
Moritz
--
To UNSUBSCRIBE, email to debian-devel-
Russ Allbery schrieb:
> Paul Wise 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 we had followed tha
Nikolaus Rath schrieb:
> Moritz Muehlenhoff 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 extensions written i
Andreas Metzler schrieb:
> In gmane.linux.debian.devel.general Kees Cook wrote:
>> I would like to propose a release goal of enabling hardening build flags[1]
>> for all C/C++ packages in the archive[2]. For Wheezy, specific sub-goals are
>> being chosen.
> [...]
>
> Hello,
> Is there any point i
1 - 100 of 115 matches
Mail list logo