Bug#657076: Updating and maintaining barry in Debian / Ubuntu
Hi,
Chris Frey wrote (29 May 2012 09:45:15 GMT) :
> On Tue, May 29, 2012 at 10:48:43AM +0200, intrigeri wrote:
>> Commit 85a9d87f makes debian/rules stop passing
>> "DEB_BUILD_MAINT_OPTIONS = hardening=+all" to dpkg-buildflags.
> I was doing testing with and without the revert, and the lintian
> tests did not improve.
I doubt Lintian results indicate anything relevant to PIE or bindnow.
The (probable false positives) Lintian warnings we've seen were about
possibly not fortified functions, which is totally orthogonal,
I believe, to PIE and bindnow.
More useful ways to check if PIE and bindnow are being used are:
- hardening-check(1) (from the hardening-includes package)
- build logs: see what arguments are passed to the compiler, linker
and friends.
> I'm curious why we would force all hardening options on when it is
> not the default for Debian.
We would do so to get better security, very cheaply.
> I assume hardening defaults were chosen for good reason.
They were chosen to be *safe* *defaults* that could be applied,
without too much thinking, to a huge majority of the packages we ship.
The idea was to make it easy, for people who work on securing Debian,
to push hardening patches to package maintainers, without seeing them
run away, totally scared, after it broke one of their package once due
to incompatibility issues. However, all the work on hardening options
(see dpkg-buildflags(1)) was done in a way that makes it easy to add,
or remove, hardening options depending on what's possible / easy /
doable / a pain to maintain, balanced with the security gains.
Moreover, the hardening documentation I've pointed you at clearly
encourages maintainers to try out the full-blown hardening options
set, if possible. It's not as if we were doing anything against Debian
by following the Debian security team advice :)
AFAIK, no large general-purpose distro builds all software with PIE by
default; this is due to some performance problems on register-starved
architectures, and the fact it breaks quite some software. So, the
only practical way for Debian to get more hardening thanks to PIE is
to have maintainers enable it pro-actively, on a package by package
basis. Which is what I am kindly asking you to do :)
> Doesn't this make it harder to adjust the whole distro at once,
> if needed?
It would, but I think this is a theoretical case: I doubt we can ever
do any distro-wide change wrt. PIE.
>> What do you think?
> First, some questions: are my source packages not the files that
> will be uploaded?
They are part of what can be uploaded. I also have to build and upload
the corresponding binary packages.
> Do you need to recreate them for some reason?
I'd slightly prefer to re-create the source package from a Git tag
every time, to make sure the procedure works well for people who are
not you, to ensure I, or anyone else, can prepare a security update
against barry while you're in vacation, in a way that integrates well
with your usual workflow.
> I had assumed that uploading was easy if you had accurate, signed
> source packages from me.
Uploading is easy, but sponsoring means quite more than
blindly uploading.
> What changes do you check when you use git?
I read in details every change to debian/, and I glance over the
upstream changes too.
> Is it not suitable to do:
> git log -p barry-0.18.2..barry-0.18.3 -- debian
> to see what changed?
This is *exactly* what I'd like to be able to do, and see it reflect
exactly the source package I'm supposed to review and upload.
This is not the case currently: given your current workflow, I have to
import the tarball in Git myself, to compare it to the new tag.
I can't just review object 1, upload object 2, and do as if object
1 and object 2 are obviously the same, see?
So, given your current workflow, what I do is use debdiff to compare
the previous and new source packages, and in parallel try to match
this with the Git history by hand to get the reason behind every
change. This is not something I like to do by hand.
> Also, the debian/ directory lives in master, and if I understand
> correctly, you're asking for it to be moved. This makes no sense to
> me. I can see creating new tags for Debian-only -1, -2, releases,
> but not splitting debian/ into its own little world.
I fully understand why mixing upstream code and Debian packaging makes
things easier to you. I also do maintain a few packages I am upstream
for, and this splitting clearly makes things look a bit artificial,
and means a bit more work on the short term.
What you'd like would be to have a perfect match between upstream and
Debian versions, between upstream and Debian source tree, which is
what native packages are for.
However, barry is clearly no native package, and e.g. you may have to
branch e.g. a wheezy branch out of an old state of you master branch
at some point, e.g. to prepare a stable or security update, or
a backport.
At this point, you'll realize your upstream source tree may live an
unique live, but the debian/ directory cannot really do so, is
inherently multiple, and frequently several instances of it must be
maintained in parallel... which calls for a branch per instance of
debian/ directory, which more or less means, in practice, a branch per
Debian repository (stable, stable updates, stable security, unstable,
experimental, and perhaps Ubuntu too, etc.) -- at this point, having
debian/ live in the master upstream branch becomes, believe me,
a major pain to deal with.
But well, this being said, just take my mere advice for what it is,
make your own decision, and deal with the consequences -- perhaps
barry won't ever need a stable or security update, and perhaps things
won't get as complex as I am implying :)
> As for pristine-tar, my initial reaction is that I'm disappointed
> that I can't get rid of it yet. I had hoped that by taking on the
> role of maintainer, I could avoid that waste.
What waste, exactly?
> If I find a way to make git-buildpackage run for you as expected,
> without pristine-tar, would that be satisfactory? Maybe that's
> impossible, but I'd really like to get rid of that dependency.
This would be satisfactory, but indeed it looks impossible to me:
I don't know how you can ship a source package purely over Git without
using pristine-tar. If you go on not using pristine-tar, I still have
to fetch both from Git and (at least) the orig.tar.gz from a painful
web site.
pristine-tar was created *exactly* to allow shipping, over Git, the
tiny delta that goes between a Git tree and a .orig.tar.gz.
> If worse comes to worst, would it be possible to get a git repo
> somewhere on debian.org that I could push pristine-tar stuff to?
Sure. We could easily get a Git repository in collab-maint on Alioth.
> I'm sure I could script something to do it automatically, but
> I don't want that waste in upstream, and it seems rude to put it on
> repo.or.cz too.
Rude? It looks like you think pristine-tar brings massive amounts of
data in Git. When I imported old barry releases into Git, every one
added a few dozens kB to Git, which does look tiny to me compared to
the size of the barry source tree.
Cheers,
--
intrigeri
| GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
Reply to: