[lkml]   [2003]   [Nov]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: BK2CVS problem

    On Wed, 5 Nov 2003, Andreas Dilger wrote:
    > Granted that this was not a break in BK itself the event is still alarming.
    > It makes me wonder if there is some way we can start using GPG signatures
    > with BK itself so that you can get proof-positive that a CSET annotated
    > as from davem really is from the David Miller we know and trust.

    A few things do make the current system _fairly_ secure. One of them is
    that if somebody were to actually access the BK trees directly, that would
    be noticed immediately: when I push to the places I export from, the push
    itself would fail due to having an unexpected changeset in the target that
    I don't have on my local tree. So I'd notice that kind of stuff

    And that's likely to be true of all other BK users too: the public trees
    are just replicas of the trees people actually _work_ on, so if the public
    tree has something unexpected, trying to update them just won't work. You
    just can't push to a tree that isn't a subset of what you already have.

    So any BK corruption would have to come from the private trees, not the
    public ones. Which tend to be better secured, exactly because they are
    private (ie they don't have things like cvspserver etc public servers). I
    suspect most of us have firewalls that just don't accept any incoming
    connections - I know I do.

    I think it's telling that it was the CVS tree and not the BK tree that
    somebody tried to corrupt.


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2009-11-18 23:46    [W:0.022 / U:15.440 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site