[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Please try expo.debian.net -- a replacement for mentors.debian.net

Hi Asheesh,

On Tue, Jul 26, 2011 at 05:00:45PM -0400, Asheesh Laroia wrote:
> On Tue, 26 Jul 2011, Kilian Krause wrote:
> >- detect whether debian/watch is there and useful
> >- if so and if the version is not mangled (like ~dfsg etc.), run uscan
> > --force-download in a patched version that does not involve uupdate or
> > svn-update (i.e. does call any programs that an "attacker" might want to
> > turn against us)
> >- diff that against the orig.tar.* uploaded
> >- if different, put up a warning, unpack both and list the diff -urN if any
> Out loud, I just found myself saying: "Whoooooaaaa so cool!"
> That would be pretty awesome. I would completely love to see that.


> >I'm not entirely sure if we want to run get-orig-source targets to
> >rebuild ~dfsg tarballs and compare them. Or rather how we could
> >sandbox that process to make sure we're on the safe side but still
> >don't allow any attacker to abuse the system.
> To do get-orig-source would be pretty amazingly great. You're right
> that safety would a challenge when running code from within the
> debian/rules file.
> It would be pretty superb to lock that process into a chroot. I
> would suggest using something like sbox
> <http://packages.debian.org/lenny/sbox-dtc> to do it.

just for the record: neither chroot nor sbox will be sufficient to protect a
production system. Maybe LXC will be, maybe SELinux, maybe XEN. That's the
least protection I'd settle for. Maybe even a combination of those (if we
put up an official description we'll be pretty open to being hacked due to
the foreseeable results of our architecture). Thus neither document too
publically how we do it nor what the exact internal versions are.

This being said, of course bringing more complexity will also make the
construct more fragile and more error-prone (read: more unsafe). That's why
I said it'd be a challenge to put this up in a manageable and yet secure

Most probably an interpreter with a whitelisting of commands will come in
most handy in the end.  ;-)

Best regards,

Attachment: signature.asc
Description: Digital signature

Reply to: