On Tue, Jun 22, 2010 at 10:37 AM, Andres P <aepd87@xxxxxxxxx> wrote: > On Tue, Jun 22, 2010 at 4:26 AM, Philipp Überbacher > <hollunder@xxxxxxxxxxx> 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@xxxxxxxxxxxxxx> 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@xxxxxxxxx> 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
