On Tue, 22 Jun 2010 07:11:25 +0800 Ng Oon-Ee 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

On Jun 21, 2010, at 6:37 PM, Andres P wrote:

2010/6/21 Ng Oon-Ee :

...

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 6:53 PM, Andres P wrote:

On Mon, Jun 21, 2010 at 7:17 PM, C Anthony Risinger 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 Mon, Jun 21, 2010 at 10:16 PM, Allan McRae 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:53 PM, Dan McGee wrote:

On Mon, Jun 21, 2010 at 10:27 PM, C Anthony Risinger wrote:

...

On Mon, Jun 21, 2010 at 10:16 PM, Allan McRae 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 Tue, 22 Jun 2010 13:16:23 +1000 "Allan McRae" 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

On Tue, Jun 22, 2010 at 4:26 AM, Philipp Überbacher 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 2:51 PM, C Anthony Risinger 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 Tue, Jun 22, 2010 at 6:49 PM, Allan McRae 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  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 Mon, 2010-06-21 at 18:47 -0500, C Anthony Risinger wrote:

On Jun 21, 2010, at 6:37 PM, Andres P wrote:

...

2010/6/21 Ng Oon-Ee :

...

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.