[arch-general] Important notice on the Arch Security Team to the whole Arch Linux community.
Dear Arch community, I thought I'd post a follow up on some of the things said in the last thread I created on this list. I'm using upper case for headings just to make things easier to read and not to shout! Please post or cc all follow ups to the Arch General list, and read this message carefully before replying. 1. DISCUSSION ABOUT SECURITY ON ARCH-GENERAL AND THE GOOGLE GROUP It's been mentioned that because my proposition for an arch-security list was rejected, I'm trying to circumvent that by posting stuff about setting up a security team to arch-general. That's not my intention. I am proposing a compromise. Internal communications on security issues will be kept to the Google Group. An irregular 'newsletter' will be posted to arch-general when major things are done to keep Arch users who are not on the Google Group informed. Also when security alerts do eventually start getting issued they *will* be posted to arch-general. I believe that all Arch users should benefit from the work that will be getting done. Doing it this way will keep email traffic on security issues on arch-general to a minimum. 2. THE RELEVANCE AND USEFULNESS OF AN ARCH SECURITY TEAM. There's been some murmurings that this undertaking is pointless. Happily this has mostly come from users and not developers. In fact it has the direct or indirect support of at least two Arch developers, Pierre Schmitz and Hugo Doria: http://www.osnews.com/story/22692/Arch_Linux_Team/page6/ This is just as much an experiment as anything else. It remains to be seen if setting up an Arch Security team is worthwhile. Evidence based on other distros seems to point to the fact that it is. If you are not convinced that's fine, but please provide constructive criticism and not mindless trolling like suggesting naming a security team after a Mexican food dish or the British English slang word for buttocks. If you don't want any part of this, other than the odd email on arch-general you won't be hindered or pestered in any way. 3. WE NEED YOUR HELP There is no Arch security team as of now. Hopefully there soon will be. If you want to help it would be helpful if you have the following skills or experience: -Ability to modify PKGBUILDs, rebuild and test packages. -Know how to patch and compile software -Are willing to subscribe to several security related mailing lists -Know basic usage of GPG in email -Are willing to hang out in the arch-security IRC channel -Are willing to file bugs in the Arch bug tracker You don't need to be security guru, just willing to help out, learn and with a desire to make our favourite Linux distro even better than it already is. If you want to help out please subscribe to the Google Group and submit a message with the subject "I want to join the team", without quotes. http://groups.google.com/group/arch-security If you don't have or don't want to create a Google account, please send me a personal email and I'll add you to the member list. 4. SCOPE OF THE SECURITY TEAM It is my intention that at this point, the security team will only deal with finding and fixing security related issues. This will entail providing interim pkgbuilds, reporting issues on the bug tracker and sending out alert notices via email. All communications to the 'outside world' (emails, wiki articles etc) from the team will state that (for now) the team's work is completely unofficial and unsupported by the Arch Developers. This is to avoid sullying the reputation of the Arch developers. 5. LONG TERM GOALS Most Arch stuff starts out as external projects than then merge with the main distro. If our work turns out to be useful, and I hope it will be, I would like us to become an official Arch Team. We could then having something like Debian does, with two mailing lists, one for security discussion and a read only list where announcements are posted. The details of this remain to be determined as this initiative is only just starting out. 6. FINAL WORDS I hope this message has made things a bit clearer for everyone. I won't start on the actual process/policy documents till after this weekend coming as I have some things to attend to before that. Of course feel free to suggest things on the Google Group, I'd like to make things as open and transparent over there as possible. If you have any questions, don't hesitate to post on the Google Group or email me personally. Thanks, Ananda Samaddar
On Mon, 2010-06-21 at 19:28 +0100, Ananda Samaddar wrote:
5. LONG TERM GOALS
Most Arch stuff starts out as external projects than then merge with the main distro. If our work turns out to be useful, and I hope it will be, I would like us to become an official Arch Team. We could then having something like Debian does, with two mailing lists, one for security discussion and a read only list where announcements are posted. The details of this remain to be determined as this initiative is only just starting out.
I'd still like to know how this replaces/conflicts with Arch policy for 'as upstream as possible'. I'm aware that just starting out the answer may just be "we don't know yet", but for me one of the benefits of Arch is that all packages are close to upstream (and thus its easy to discuss bugs with upstream, which may not be the case with 5-10 security-patches from git/svn).
On Tue, 22 Jun 2010 07:11:25 +0800 Ng Oon-Ee <ngoonee@gmail.com> wrote:
I'd still like to know how this replaces/conflicts with Arch policy for 'as upstream as possible'. I'm aware that just starting out the answer may just be "we don't know yet", but for me one of the benefits of Arch is that all packages are close to upstream (and thus its easy to discuss bugs with upstream, which may not be the case with 5-10 security-patches from git/svn).
I think you answered your own question with the 'we don't know yet' statement. I'm looking to get in with the archserver.org guys and the only response I've had so far from them seems to be positive. So the Google Group may well be shutting down with everything moving to archserver.org's infrastructure. There's also already one person who wants to join the team and help. Basically watch this space and hopefully we'll have something on the go very soon. thanks, Ananda
2010/6/21 Ng Oon-Ee <ngoonee@gmail.com>:
bugs with upstream, which may not be the case with 5-10 security-patches from git/svn).
This is just pessimistic outlook. Having patches means that you're actually contributing upstream instead of leaching the latest ver every 3 weeks. People need to stop with the notion that patching is bad. As long as you submit upstream, it's anything but a detriment. Upstream *wants* you to fix their crap. Andres P
On Jun 21, 2010, at 6:37 PM, Andres P <aepd87@gmail.com> wrote:
2010/6/21 Ng Oon-Ee <ngoonee@gmail.com>:
bugs with upstream, which may not be the case with 5-10 security- patches from git/svn).
This is just pessimistic outlook. Having patches means that you're actually contributing upstream instead of leaching the latest ver every 3 weeks.
People need to stop with the notion that patching is bad. As long as you submit upstream, it's anything but a detriment. Upstream *wants* you to fix their crap.
Andres P
He said from git/svn... ie backporting, not contributing. C Anthony
On Mon, Jun 21, 2010 at 7:17 PM, C Anthony Risinger <anthony@extof.me> wrote:
He said from git/svn... ie backporting, not contributing.
...? Once they're in svn they're confined to abs? Besides, it's not like there's anything keeping upstream from looking at obsd cvs, Debian's bug tracker, nor Arch's svn repo, etc. Andres P
On Mon, Jun 21, 2010 at 6:53 PM, Andres P <aepd87@gmail.com> wrote:
On Mon, Jun 21, 2010 at 7:17 PM, C Anthony Risinger <anthony@extof.me> wrote:
He said from git/svn... ie backporting, not contributing.
...?
Once they're in svn they're confined to abs? Besides, it's not like there's anything keeping upstream from looking at obsd cvs, Debian's bug tracker, nor Arch's svn repo, etc.
Andres P
i'm not trying to discourage anyone from pursuing an 'arch security team', or whatever you want to call it. as someone who makes their living writing softwares, you cannot just whip up comprehensive patches for any old project; it takes a significant amount of time to learn the codebase. now the alternative; pulling in obscure fixes from here and there that you don't even really understand to repair problems that may only exist for a short while, or may not even been real problems is a fool's errand. how do you know _why_ upstream wrote the code the way they did? are you sure it's really a bug/hole? are you sure when you backport stuff from trunk/head you won't be introducing more/worse holes? are you sure the backported commit doesn't depend on other commits that currently only exist in trunk? do you trust other distros, ie not authors, to make these decisions for you? one of my favorite things about Arch is not just following the latest releases of upstream, but trying to follow the latest _configuration_ of upstream as well. no one knows a software's internals better than the people who wrote it; let me decide how to make it fit in my environment, because _i_ know that better. dropping privileges and things like that _is_ good practice... but as i said in the other thread: _ultimately_, security is the duty of those deploying to production, not those writing software or packaging it for a generic audience. sure, you could run every application in an LXC container by default with a private rootfs/namespaces, and slap some smack policies or grsecurity or whatever fancy pants layers of indirection you conceive... but should the other 99% of users have to deal with that level of paranoia, and have to undo all that junk when it's not what they need? no. upstream may allow the ability to automatically run in a chroot/container/etc., but it's never the default. why? it's not their job to know how you intend to deploy. it's not Arch's job either. my point of this ramble if there is one, is that personally, i don't want _anyone_ other than upstream to make security decisions regarding their software. if Arch started naively backporting stuff based of the latest alert from XYZ, i wouldn't be sticking around to long. even if an security hole is found i _don't_ want the fix to be included by default, unless it came from upstream in the form of a new release, which Arch would just pick up as usual. thus, in my opinion, an 'arch security team' would be most effective by limiting itself to: 1) alerting others that wish to be alerted of any known/potential/outstanding holes 2) making sure upstream is aware, and getting an ETA of inclusion into mainline 3) adding many wiki pages on how to lock down daemons/applications + best practices 4) making sane recommendations to the development team that does _not_ include patches of any kind or wild changes to default configurations if they stick to that, i'm all about it; otherwise, they're just in the way. C Anthony
On 22/06/10 12:07, C Anthony Risinger wrote:
my point of this ramble if there is one, is that personally, i don't want _anyone_ other than upstream to make security decisions regarding their software.if Arch started naively backporting stuff based of the latest alert from XYZ, i wouldn't be sticking around to long. even if an security hole is found i _don't_ want the fix to be included by default, unless it came from upstream in the form of a new release, which Arch would just pick up as usual.
Then you should probably move along...
find /var/abs -name *CVE* /var/abs/extra/libmikmod/libmikmod-CVE-2009-0179.patch /var/abs/extra/xmms/xmms-1.2.11-CVE-2007-0653.0654.patch /var/abs/extra/alpine/CVE-2008-5514.patch /var/abs/extra/libtiff/libtiff-CVE-2009-2285.patch /var/abs/extra/libtiff/tiff-3.9.0-CVE-2009-2347.patch /var/abs/extra/id3lib/id3lib-3.8.3-CVE-2007-4460.patch /var/abs/core/expat/CVE-2009-3720.patch /var/abs/core/expat/CVE-2009-3560.patch
and these are just the patches named for the security issue they fix. The point is that the developers around here already patch for security issues. The only change that I think that a security team will achieve is to notify me (as a developer) of issues that I have overlooked on the upstream mailing lists and file a bug report. It is a bonus if the issue is pre-analyzed for me and all relevant links supplied so I can assess it quickly myself and release a fixed package if I deem that being suitable. Allan
On Mon, Jun 21, 2010 at 10:16 PM, Allan McRae <allan@archlinux.org> wrote:
On 22/06/10 12:07, C Anthony Risinger wrote:
my point of this ramble if there is one, is that personally, i don't want _anyone_ other than upstream to make security decisions regarding their software.if Arch started naively backporting stuff based of
the latest alert from XYZ, i wouldn't be sticking around to long. even if an security hole is found i _don't_ want the fix to be included by default, unless it came from upstream in the form of a new release, which Arch would just pick up as usual.
Then you should probably move along...
find /var/abs -name *CVE* /var/abs/extra/libmikmod/libmikmod-CVE-2009-0179.patch /var/abs/extra/xmms/xmms-1.2.11-CVE-2007-0653.0654.patch /var/abs/extra/alpine/CVE-2008-5514.patch /var/abs/extra/libtiff/libtiff-CVE-2009-2285.patch /var/abs/extra/libtiff/tiff-3.9.0-CVE-2009-2347.patch /var/abs/extra/id3lib/id3lib-3.8.3-CVE-2007-4460.patch /var/abs/core/expat/CVE-2009-3720.patch /var/abs/core/expat/CVE-2009-3560.patch
and these are just the patches named for the security issue they fix.
The point is that the developers around here already patch for security issues. The only change that I think that a security team will achieve is to notify me (as a developer) of issues that I have overlooked on the upstream mailing lists and file a bug report. It is a bonus if the issue is pre-analyzed for me and all relevant links supplied so I can assess it quickly myself and release a fixed package if I deem that being suitable.
indeed. 2007/8/9? are these patches from years ago, for dead software (xmms?)? i don't know the state of the others. alright, so you're patching stuff... why? why are such old patches not in upstream? if things were done appropriately there wouldn't be a need for intermediary patches because glaring security holes are quickly absorbed into upstream. or... whats the deal here? i don't get the need to carry these around. at any rate i don't agree with it but meh, i'm just a worker bee :-) C Anthony
On Mon, Jun 21, 2010 at 10:27 PM, C Anthony Risinger <anthony@extof.me> wrote:
On Mon, Jun 21, 2010 at 10:16 PM, Allan McRae <allan@archlinux.org> wrote:
On 22/06/10 12:07, C Anthony Risinger wrote:
my point of this ramble if there is one, is that personally, i don't want _anyone_ other than upstream to make security decisions regarding their software.if Arch started naively backporting stuff based of
the latest alert from XYZ, i wouldn't be sticking around to long. even if an security hole is found i _don't_ want the fix to be included by default, unless it came from upstream in the form of a new release, which Arch would just pick up as usual.
Then you should probably move along...
find /var/abs -name *CVE* /var/abs/extra/libmikmod/libmikmod-CVE-2009-0179.patch /var/abs/extra/xmms/xmms-1.2.11-CVE-2007-0653.0654.patch /var/abs/extra/alpine/CVE-2008-5514.patch /var/abs/extra/libtiff/libtiff-CVE-2009-2285.patch /var/abs/extra/libtiff/tiff-3.9.0-CVE-2009-2347.patch /var/abs/extra/id3lib/id3lib-3.8.3-CVE-2007-4460.patch /var/abs/core/expat/CVE-2009-3720.patch /var/abs/core/expat/CVE-2009-3560.patch
and these are just the patches named for the security issue they fix.
The point is that the developers around here already patch for security issues. The only change that I think that a security team will achieve is to notify me (as a developer) of issues that I have overlooked on the upstream mailing lists and file a bug report. It is a bonus if the issue is pre-analyzed for me and all relevant links supplied so I can assess it quickly myself and release a fixed package if I deem that being suitable.
indeed. 2007/8/9? are these patches from years ago, for dead software (xmms?)? i don't know the state of the others.
alright, so you're patching stuff... why? why are such old patches not in upstream? if things were done appropriately there wouldn't be a need for intermediary patches because glaring security holes are quickly absorbed into upstream. or... whats the deal here? i don't get the need to carry these around.
at any rate i don't agree with it but meh, i'm just a worker bee :-)
Do you honestly think releasing software is that easy? It *sucks*. It is the least enjoyable part of being an open-source developer. They probably are in upstream and they haven't done a release for some very good raeson, or upstream is no longer well-maintained. Does that mean we should leave people vulnerable because of some party line we have? Heck no. -Dan
On Mon, Jun 21, 2010 at 10:53 PM, Dan McGee <dpmcgee@gmail.com> wrote:
On Mon, Jun 21, 2010 at 10:27 PM, C Anthony Risinger <anthony@extof.me> wrote:
On Mon, Jun 21, 2010 at 10:16 PM, Allan McRae <allan@archlinux.org> wrote:
On 22/06/10 12:07, C Anthony Risinger wrote:
my point of this ramble if there is one, is that personally, i don't want _anyone_ other than upstream to make security decisions regarding their software.if Arch started naively backporting stuff based of
the latest alert from XYZ, i wouldn't be sticking around to long. even if an security hole is found i _don't_ want the fix to be included by default, unless it came from upstream in the form of a new release, which Arch would just pick up as usual.
Then you should probably move along...
find /var/abs -name *CVE* /var/abs/extra/libmikmod/libmikmod-CVE-2009-0179.patch /var/abs/extra/xmms/xmms-1.2.11-CVE-2007-0653.0654.patch /var/abs/extra/alpine/CVE-2008-5514.patch /var/abs/extra/libtiff/libtiff-CVE-2009-2285.patch /var/abs/extra/libtiff/tiff-3.9.0-CVE-2009-2347.patch /var/abs/extra/id3lib/id3lib-3.8.3-CVE-2007-4460.patch /var/abs/core/expat/CVE-2009-3720.patch /var/abs/core/expat/CVE-2009-3560.patch
and these are just the patches named for the security issue they fix.
The point is that the developers around here already patch for security issues. The only change that I think that a security team will achieve is to notify me (as a developer) of issues that I have overlooked on the upstream mailing lists and file a bug report. It is a bonus if the issue is pre-analyzed for me and all relevant links supplied so I can assess it quickly myself and release a fixed package if I deem that being suitable.
indeed. 2007/8/9? are these patches from years ago, for dead software (xmms?)? i don't know the state of the others.
alright, so you're patching stuff... why? why are such old patches not in upstream? if things were done appropriately there wouldn't be a need for intermediary patches because glaring security holes are quickly absorbed into upstream. or... whats the deal here? i don't get the need to carry these around.
at any rate i don't agree with it but meh, i'm just a worker bee :-)
Do you honestly think releasing software is that easy? It *sucks*. It is the least enjoyable part of being an open-source developer.
They probably are in upstream and they haven't done a release for some very good raeson, or upstream is no longer well-maintained. Does that mean we should leave people vulnerable because of some party line we have? Heck no.
hmm, so the fundamental problem is that the word 'upstream' implies a unity that does not exist. at this point i would enter conversation about reconciling individual 'upstreams' to a common backend, such that distributions/contributors/users may immediately benefit from each others work; a p2p application and public software broadcasting framework upon which distributions could be founded... a different topic :-) i suppose... unmaintained should have patches and very small, concise changes to poorly maintained, and maybe even _very_ few to regularly maintained. yet, most security related alerts are for higher profile applications; a more immediate response i would think? i simply don't want to see a collective effort to preempt upstream; i prefer to manually digress from vanilla, and i'm probably a minority. C Anthony
On 22/06/10 15:59, C Anthony Risinger wrote:
On Mon, Jun 21, 2010 at 10:53 PM, Dan McGee<dpmcgee@gmail.com> wrote:
On Mon, Jun 21, 2010 at 10:27 PM, C Anthony Risinger<anthony@extof.me> wrote:
On Mon, Jun 21, 2010 at 10:16 PM, Allan McRae<allan@archlinux.org> wrote:
On 22/06/10 12:07, C Anthony Risinger wrote:
my point of this ramble if there is one, is that personally, i don't want _anyone_ other than upstream to make security decisions regarding their software.if Arch started naively backporting stuff based of
the latest alert from XYZ, i wouldn't be sticking around to long. even if an security hole is found i _don't_ want the fix to be included by default, unless it came from upstream in the form of a new release, which Arch would just pick up as usual.
Then you should probably move along...
find /var/abs -name *CVE* /var/abs/extra/libmikmod/libmikmod-CVE-2009-0179.patch /var/abs/extra/xmms/xmms-1.2.11-CVE-2007-0653.0654.patch /var/abs/extra/alpine/CVE-2008-5514.patch /var/abs/extra/libtiff/libtiff-CVE-2009-2285.patch /var/abs/extra/libtiff/tiff-3.9.0-CVE-2009-2347.patch /var/abs/extra/id3lib/id3lib-3.8.3-CVE-2007-4460.patch /var/abs/core/expat/CVE-2009-3720.patch /var/abs/core/expat/CVE-2009-3560.patch
and these are just the patches named for the security issue they fix.
The point is that the developers around here already patch for security issues. The only change that I think that a security team will achieve is to notify me (as a developer) of issues that I have overlooked on the upstream mailing lists and file a bug report. It is a bonus if the issue is pre-analyzed for me and all relevant links supplied so I can assess it quickly myself and release a fixed package if I deem that being suitable.
indeed. 2007/8/9? are these patches from years ago, for dead software (xmms?)? i don't know the state of the others.
alright, so you're patching stuff... why? why are such old patches not in upstream? if things were done appropriately there wouldn't be a need for intermediary patches because glaring security holes are quickly absorbed into upstream. or... whats the deal here? i don't get the need to carry these around.
at any rate i don't agree with it but meh, i'm just a worker bee :-)
Do you honestly think releasing software is that easy? It *sucks*. It is the least enjoyable part of being an open-source developer.
They probably are in upstream and they haven't done a release for some very good raeson, or upstream is no longer well-maintained. Does that mean we should leave people vulnerable because of some party line we have? Heck no.
hmm, so the fundamental problem is that the word 'upstream' implies a unity that does not exist. at this point i would enter conversation about reconciling individual 'upstreams' to a common backend, such that distributions/contributors/users may immediately benefit from each others work; a p2p application and public software broadcasting framework upon which distributions could be founded...
a different topic :-)
i suppose... unmaintained should have patches and very small, concise changes to poorly maintained, and maybe even _very_ few to regularly maintained. yet, most security related alerts are for higher profile applications; a more immediate response i would think?
i simply don't want to see a collective effort to preempt upstream; i prefer to manually digress from vanilla, and i'm probably a minority.
Not really. We do like vanilla software and aim for that in our repos. But it not an unbreakable rule. What I would like to see one day is a header on all patches detailing where they come from and what they do. Something like in Debian of LFS. Allan
On Tue, 22 Jun 2010 13:16:23 +1000 "Allan McRae" <allan@archlinux.org> wrote:
The point is that the developers around here already patch for security issues. The only change that I think that a security team will achieve is to notify me (as a developer) of issues that I have overlooked on the upstream mailing lists and file a bug report. It is a bonus if the issue is pre-analyzed for me and all relevant links supplied so I can assess it quickly myself and release a fixed package if I deem that being suitable.
Allan
This is exactly what we plan to do, with the addition of providing interim PKGBUILDs (with a disclaimer that they are unofficial) and announcements when a security related bug is fixed by a package update. Such interim PKGBUILDs would be peer-reviewed by the Security Team and submitted with the relevant bug report to aid the package maintainer. I can't see how this is not useful. It will also lighten the workloads of the devs and package maintainers. Ananda
Excerpts from Andres P's message of 2010-06-22 01:53:20 +0200:
On Mon, Jun 21, 2010 at 7:17 PM, C Anthony Risinger <anthony@extof.me> wrote:
He said from git/svn... ie backporting, not contributing.
...?
Once they're in svn they're confined to abs? Besides, it's not like there's anything keeping upstream from looking at obsd cvs, Debian's bug tracker, nor Arch's svn repo, etc.
Andres P
Sure, like any dev will be going through every possible bug tracker, repo or ask any possible user to find patches for his app. Don't be ridiculous. If you write a patch that's not distro specific, then it's your job to get it to upstream, it's the only way it could possibly work. The beauty of arch is that the patch you just wrote is most likely against the latest release, and upstream will likely be happy to get it. -- Regards, Philipp -- "Wir stehen selbst enttäuscht und sehn betroffen / Den Vorhang zu und alle Fragen offen." Bertolt Brecht, Der gute Mensch von Sezuan
On Tue, Jun 22, 2010 at 4:26 AM, Philipp Überbacher <hollunder@lavabit.com> wrote:
Sure, like any dev will be going through every possible bug tracker, repo or ask any possible user to find patches for his app. Don't be ridiculous. If you write a patch that's not distro specific, then it's your job to get it to upstream,
So it's not just take the time to write the fix, you also have to make sure you rebase it every time theres a white space patch. Let upstream know about your repo and then both can work comfortably... You're implying that upstream is too important or what have you. What about the inverse?
it's the only way it could possibly work. The beauty of arch is that the patch you just wrote is most likely against the latest release, and upstream will likely be happy to get it.
Ok, the beauty of openbsd is that they're running a BIND version that's been patched to the point of no recognition. They have confidence in their skills instead of quitting before giving it a shot. This arch security news group sounds great. Specially if they intend to sit down and code. Andres P
On Tue, Jun 22, 2010 at 10:37 AM, Andres P <aepd87@gmail.com> wrote:
On Tue, Jun 22, 2010 at 4:26 AM, Philipp Überbacher <hollunder@lavabit.com> wrote:
Sure, like any dev will be going through every possible bug tracker, repo or ask any possible user to find patches for his app. Don't be ridiculous. If you write a patch that's not distro specific, then it's your job to get it to upstream,
So it's not just take the time to write the fix, you also have to make sure you rebase it every time theres a white space patch.
Let upstream know about your repo and then both can work comfortably...
You're implying that upstream is too important or what have you. What about the inverse?
this is just not how it works. yes, you should rebase if your following _their_ project; it's one command, if that (you can setup automatic rebasing when pulling). if you submit patches, you don't need to re-submit unless your patch was affected by subsequent merges. they don't want to follow 17 obscure forks and figure out how to merge the work... really? yes, upstream _is_ more important. if you must have control, publicly fork the work and go from there. it's not helping anyone by providing alternative builds in the same name, confusing users, and annoying authors.
it's the only way it could possibly work. The beauty of arch is that the patch you just wrote is most likely against the latest release, and upstream will likely be happy to get it.
Ok, the beauty of openbsd is that they're running a BIND version that's been patched to the point of no recognition. They have confidence in their skills instead of quitting before giving it a shot.
then in my opinion they aren't running BIND. why aren't they pushing back to upstream? if they have conflicts in the project's direction: "publicly fork the work and go from there". it's only fair to the original authors. lastly, this:
This arch security news group sounds great. Specially if they intend to sit down and code.
plus: On Tue, Jun 22, 2010 at 8:37 AM, Ananda Samaddar <ananda@samaddar.co.uk> wrote:
.......... with the addition of providing interim PKGBUILDs ..........
is precisely what i _don't_ want to see happening, at all, bad bad bad. if you want to code, spectacular, learn the app, write code, and submit to upstream. i just am having a hard time believing that you are not only going to track down holes, but have the competence to properly fix them, for all the reasons i've already specified. this is nothing personal, i just flat out don't trust you :-) or a handful of volunteers, and would prefer you limit yourselves to more productive/practical actions like alerts, guides, and communicating with upstream. the overwhelming majority of security holes are not from holes in applications, but holes in deployment methods and careless administration. script kiddies will hit your server with a list of known passwords and an assortment of other goodies; _this_ is noteworthy documentation, an "Arch Security Beginner's Guide", and annotations to existing guides. the likely-hood of falling prey to a 0-day exploit is far lower. example: SSH 0-day exploit is released. bang! you crack out your interim PKGBUILD and crack a beer because your safe right? whoops, because this is a production machine (from a message a couple hours ago): On Tue, Jun 22, 2010 at 10:23 AM, Sergey Manucharian <ingeniware@gmail.com> wrote:
.......... Everything work fine, but I'm doing updates only ones in 2-3 months. ..........
what?? so i have to also upgrade lib XYZ to get this to work? wait, let's just backport to version X... damn! Sandy Squirrel updated a month ago, so she's running version Y... do you see where i'm headed here? are you going to provide fixes for every possible package update that occurred in the last 6 months? lets say your crazy and you auto update your production machines... now your pulling in a _reactionary_ fix that if appropriate will probably be in upstream in less than a week, and they'll have a security related point-release to address it properly. these 'security repos' work alright for debian and friends because they use a controlled release schedule; there is no guesswork about the state of the system. trying to do the same for Arch is aiming for a rolling release, single-lib moving target; my crystal ball predicts headaches and worse. again, maybe i'm a minority here, but i _don't_ find patching appropriate except in rare occasions where relying on upstream is either not possible or not practical. having said all that, i _do_ think it would be cool to have lots of quality security related docs, an official security RSS feed, and maybe even output from pacman on packages that have outstanding security flags on them. use your energies to spread knowledge, let the pro's handle the nitty gritty. er, IMO :-) C Anthony
On Tue, Jun 22, 2010 at 2:51 PM, C Anthony Risinger <anthony@extof.me> wrote:
Ok, the beauty of openbsd is that they're running a BIND version that's been patched to the point of no recognition. They have confidence in their skills instead of quitting before giving it a shot.
then in my opinion they aren't running BIND. why aren't they pushing back to upstream? if they have conflicts in the project's direction: "publicly fork the work and go from there". it's only fair to the original authors.
It doesn't matter if they're not running BIND. They have a real scenario where they can test functionality. This pipe dream where every package is kept vanilla for the sake of doing so is called stagnation. Tacking on a ls from over there, a pwd from over here, a kernel from elsewhere... isn't going to help anybody develop an OS into refined product. It's going to feel like a confused crossdresser of a system. What's the point of keeping packages completely disintegrated with its surroundings? They run patched gcc, perl, ksh... etc. And they happen to be the most secure widely known bsd. Would that be possible if they catered to this vanilla fetish? No. Granted, these guys probably don't have the know-how that openbsd does, but they gotta start somewhere. What better place than the randomness that is arch? Andres P
On 23/06/10 05:21, C Anthony Risinger wrote:
example: SSH 0-day exploit is released. bang! you crack out your interim PKGBUILD and crack a beer because your safe right? whoops, because this is a production machine (from a message a couple hours ago):
On Tue, Jun 22, 2010 at 10:23 AM, Sergey Manucharian <ingeniware@gmail.com> wrote:
.......... Everything work fine, but I'm doing updates only ones in 2-3 months. ..........
what?? so i have to also upgrade lib XYZ to get this to work? wait, let's just backport to version X... damn! Sandy Squirrel updated a month ago, so she's running version Y...
do you see where i'm headed here? are you going to provide fixes for every possible package update that occurred in the last 6 months? lets say your crazy and you auto update your production machines... now your pulling in a _reactionary_ fix that if appropriate will probably be in upstream in less than a week, and they'll have a security related point-release to address it properly.
What a load of crap... Arch developers only support packages that are currently in the repo. Why would the security team do anything else. If a person is not prepared to update their system regularly, or at least when there is a known security issue in the out-of-date packages they are using, then they should be using a different distribution that makes stable snapshot releases. Also, as established earlier in the thread, some of our packages have patches for security issues that a a couple of years old because upstream has not made a new release. So the whole probably be fixed by upstream in less that a week and a point release made is just naive. Finally, this is not going to change the way development works around here. We would still be patching the software for the security bugs. It will just save the developers more time assessing bug as all the necessary information/links will be provided for us in one spot. Allan
On Tue, Jun 22, 2010 at 6:49 PM, Allan McRae <allan@archlinux.org> wrote:
On 23/06/10 05:21, C Anthony Risinger wrote:
example: SSH 0-day exploit is released. bang! you crack out your interim PKGBUILD and crack a beer because your safe right? whoops, because this is a production machine (from a message a couple hours ago):
On Tue, Jun 22, 2010 at 10:23 AM, Sergey Manucharian <ingeniware@gmail.com> wrote:
.......... Everything work fine, but I'm doing updates only ones in 2-3 months. ..........
what?? so i have to also upgrade lib XYZ to get this to work? wait, let's just backport to version X... damn! Sandy Squirrel updated a month ago, so she's running version Y...
do you see where i'm headed here? are you going to provide fixes for every possible package update that occurred in the last 6 months? lets say your crazy and you auto update your production machines... now your pulling in a _reactionary_ fix that if appropriate will probably be in upstream in less than a week, and they'll have a security related point-release to address it properly.
What a load of crap... Arch developers only support packages that are currently in the repo. Why would the security team do anything else. If a person is not prepared to update their system regularly, or at least when there is a known security issue in the out-of-date packages they are using, then they should be using a different distribution that makes stable snapshot releases.
Also, as established earlier in the thread, some of our packages have patches for security issues that a a couple of years old because upstream has not made a new release. So the whole probably be fixed by upstream in less that a week and a point release made is just naive.
Finally, this is not going to change the way development works around here. We would still be patching the software for the security bugs. It will just save the developers more time assessing bug as all the necessary information/links will be provided for us in one spot.
what, did you read that far and give up? dead/non-cooperative/poor upstreams are not the same as healthy, responsive upstreams. and yes, they do get fixed pretty quick; i can't imagine your dead upstream or upstreams that haven't released in years scenario affects too many applications, what, 1%?... and if it does, then they should either be removed completely or we should start following appropriate points in HEAD, because the project is probably obsolete or deprecated, or en route to such. i've seen several other external projects trying to address the fact that Arch moving at breakneck speed, leaving no prisoners, doesn't work too well for a production machines that can't afford to blindly upgrade junk or reboot at any moment. if so, then you have poor change management skills, and probably don't have many clients either. desktop machines? not important. in the end, i'm not particularly concerned with how people expend their energy. i personally think chasing microscopic holes in this or that is a colossal waste of time when the real security issues surround the other 99.9%; deployment. there are more pragmatic ways to safeguard against the known unknown and the unknown unknown. but alas, i'm bored; to each their own. C Anthony
On 06/22/10 19:49, Allan McRae wrote:
Also, as established earlier in the thread, some of our packages have patches for security issues that a a couple of years old because upstream has not made a new release. So the whole probably be fixed by upstream in less that a week and a point release made is just naive.
On 06/22/10 15:21, C Anthony Risinger wrote:
i just am having a hard time believing that you are not only going to track down holes, but have the competence to properly fix them, for all the reasons i've already specified.
part of the situation is, lots of upstreams don't have security competence either -- especially volunteer-run projects, but I bet some commercial undertakings don't either. So they don't make point-releases as soon as an important security issue is discovered; or they make a patch but the patch is incorrect (often established distros have, in some ways, a better sense of how to patch a security flaw than a individual upstream because the distros see a lot of security flaws -- like buffer overruns, etc). It's clear that spreading more information more quickly about security issues sounds productive, (as long as the information is as correct as can be, which a volunteer team may be able to have some fair amount of competence at, I'm guessing) -Isaac
On Mon, 2010-06-21 at 18:47 -0500, C Anthony Risinger wrote:
On Jun 21, 2010, at 6:37 PM, Andres P <aepd87@gmail.com> wrote:
2010/6/21 Ng Oon-Ee <ngoonee@gmail.com>:
bugs with upstream, which may not be the case with 5-10 security- patches from git/svn).
This is just pessimistic outlook. Having patches means that you're actually contributing upstream instead of leaching the latest ver every 3 weeks.
People need to stop with the notion that patching is bad. As long as you submit upstream, it's anything but a detriment. Upstream *wants* you to fix their crap.
Andres P
He said from git/svn... ie backporting, not contributing.
C Anthony
Thanks Anthony. I guess my statement IS unclear. @Andres I agree that contributing patches upstream is ideal, but (pessimistic outlook again) I doubt the size of the security team will be enough to allow them to write and test significant patches, which leads to the assumption that their main job would be to identify holes and grab patches from upstream (or Fedora/Debian/whatever) to fix those holes while waiting for upstream to go through whatever verification process they need. Those patches would come from a patchwork of places (upstream's git/svn, fedora/debian patch, etc.), and make it a bit harder to keep things stable.
2010/6/21 Ng Oon-Ee <ngoonee@gmail.com>:
I'd still like to know how this replaces/conflicts with Arch policy for 'as upstream as possible'. I'm aware that just starting out the answer may just be "we don't know yet", but for me one of the benefits of Arch is that all packages are close to upstream (and thus its easy to discuss bugs with upstream, which may not be the case with 5-10 security-patches from git/svn).
how 'bout things upstream doesn't take care of like pam.d policies... I seem to recall there being a request for a pam policy for login managers... as a result of my pointing out that even if your shell is false you can login graphically. -- Caleb Cushing http://xenoterracide.blogspot.com
participants (9)
-
Allan McRae
-
Ananda Samaddar
-
Andres P
-
C Anthony Risinger
-
Caleb Cushing
-
Dan McGee
-
Isaac Dupree
-
Ng Oon-Ee
-
Philipp Überbacher