[arch-general] Important notice on the Arch Security Team to the whole Arch Linux community.

[C Anthony Risinger]

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