| AfC | Hm. Found a (minor) bug with the lp:distribution/codename/package syntax | 07:06 |
|---|---|---|
| AfC | Where do I report that? | 07:06 |
| === yofel_ is now known as yofel | ||
| * thumper found a bug in bzrlib in precise | 15:45 | |
| thumper | must get around to filing a bug for it | 15:45 |
| thumper | hi jelmer | 15:46 |
| thumper | are you home? | 15:46 |
| * jelmer waves to thumper | 15:46 | |
| jelmer | no, still in Budapest.. just getting a coffee after spending the day sightseeing | 15:46 |
| jelmer | thumper: what about you? somewhere in Asia by now? | 15:47 |
| wgz | what did you see jelmer? | 15:47 |
| thumper | jelmer: no, vienna | 15:48 |
| jelmer | thumper: that's the wrong way, isn't it? | 15:48 |
| thumper | jelmer: there is an engineering manager meeting here for a few days | 15:48 |
| jelmer | wgz: jtv and I went to the museum about the Nazi/Soviet occupations, and I strolled around the river for a couple of hours | 15:49 |
| jelmer | thumper: ah! | 15:49 |
| wgz | neat. | 15:50 |
| thumper | yay precice, battery showing 4:49 to go | 15:50 |
| jelmer | yeah, it's a *really* significant improvement here too | 15:50 |
| thumper | :-| dropped to 4:15 after typing | 15:50 |
| jelmer | wgz: you made it to Norwich safely then? | 15:51 |
| wgz | what precisely is your precise bzrlib issue thumper? | 15:51 |
| thumper | if you start a python prompt from within a bzr branch, try | 15:52 |
| wgz | jelmer: yup, though it was a bit of a race in schiphol and I had to jump the security queue a bit | 15:52 |
| jelmer | I think that's spelled presaisy | 15:52 |
| thumper | from bzrlib.workingtree import WorkingTree | 15:52 |
| thumper | WorkingTree.open('.') | 15:52 |
| thumper | it'll fail | 15:52 |
| jelmer | thumper: that's fixed in bzr.dev | 15:52 |
| thumper | however if you import bzrlib.branch first, it works | 15:52 |
| thumper | jelmer: ok | 15:53 |
| wgz | and will be released in 2.5b5... probably in the coming week | 15:53 |
| jelmer | thumper: the problem is that we reduced our imports so much that the working tree module no longer imports bzrlib.bzrdir, which registers a couple of things - including the bzr native formats | 15:53 |
| thumper | kk | 15:53 |
| jelmer | thumper: so newer versions are explicitly importing from bzrlib.bzrdir in bzrlib.workingtree | 15:53 |
| wgz | we do have some test coverage holes for bzrlib being imported in non-bzr-script ways | 15:53 |
| jelmer | wgz: yeah :( | 15:54 |
| wgz | ideally people's bzrlib-using tools test suites would help | 15:56 |
| === Quintasan_ is now known as Quintasan | ||
| PCJockey | I'm new to Bazaar, so please excuse me if this answer is easily found, but I've been looking in the docs and new user info from the website. So, now I'm here to ask the experts for direction to the answer to my question. Thank-you in advance for your help!! | 20:31 |
| PCJockey | What is the design of a Bazaar repository? My primary interest is in knowing if it offers historical cryptographic integrity like a git repository does. | 20:31 |
| jelmer | PCJockey: hi | 21:07 |
| PCJockey | jelmer: Hello!! I hope you are well today...:) | 21:08 |
| jelmer | PCJockey: what do you mean with cryptographic integrity exactly? Git doesn't sign revisions in any way, though it can sign tags if you want to. | 21:08 |
| PCJockey | jelmer: I'm referring to the idea that because of each commit being named with a hash of the contents, you can go back through full history to know bit for bit it's accurate. I.E. nobody has altered the history or no media failures have altered the repo. | 21:10 |
| jelmer | PCJockey: bzr does have various mechanisms for verifying revisions contents, but it uses arbitrary unique strings to refer to revisions | 21:13 |
| jelmer | we do store the hash as part of the revision, it's just not use to reference that revision | 21:14 |
| PCJockey | jelmer: My point isn't to compare to git. Just that I know git has the feature. I also don't care what the commits are named. All I really want to know is how bazaar confirms integrity. | 21:14 |
| jelmer | PCJockey: it stores the SHA1 of the contents and verifies that, just like git does | 21:15 |
| jelmer | (currently it's SHA1, but we might swap that for something else in the future if more attacks against SHA1 arise) | 21:16 |
| PCJockey | jelmer: Got it. I guess if I had just installed it the answer would have been obvioius. I appreciate your help!! | 21:17 |
| jelmer | np | 21:19 |
| PCJockey | I look forward to trying Bazaar out now. It looks like the community has some very cool things going on! | 21:21 |
| fullermd | The two aren't exactly comparable. bzr's SHA1 doesn't help much against [competent] attacks. | 21:21 |
| PCJockey | fullermd: Oh, now that is what I wanted to know about...and I'm sorry to hear it. | 21:23 |
| PCJockey | fullermd: So, there is no assurance of repository integrity? | 21:24 |
| fullermd | The SHA1 in the revs gives excellent protection against accidental damage. For intentional, you have to look to other mechanisms. And that comes down to the eternal "what's your threat model". | 21:32 |
| PCJockey | fullermd: Admittedly I'm not too concerned about malicous attack, but it's a nice and seemingly free thing to have in the modern era, but yes the more likely threat is non-malicious. | 21:34 |
| fullermd | Security is never free :) | 21:35 |
| fullermd | The SHA1 in git doesn't provide any automatic protection against malicity (that's a word. I just decided) either, after all. Just that the way it's used compared to bzr gives it potential in that way. | 21:35 |
| PCJockey | fullermd: Even so, I'm not sure it's worth giving up the feature...comes down to an argument of how important it is to me. I guess I just want it all...:) | 21:36 |
| PCJockey | fullermd: Do you know why the bzr team made the decision not to include the capacity? | 21:37 |
| fullermd | Because using the hash as revision identifier has various drawbacks. | 21:38 |
| PCJockey | fullermd: I don't mean using it as an identifier, but implementing an alternate way of integrity assurance. | 21:41 |
| fullermd | Right, but using it as an identifier is *WHY* it has potential to be useful that way in git, but not in bzr. | 21:41 |
| PCJockey | BTW, I agree using a hash as an identifier is pretty UGLY!! | 21:41 |
| fullermd | A hash doesn't tell you anything by itself, after all. I could send you a bzr tarball and tell you the SHA1, and that doesn't give you any assurance that it's not actually a virus. | 21:42 |
| fullermd | All it would tell you is that you got the file *I* wanted you to have. To know you had the one the bzr team released, you'd have to know what that has was _supposed_ to be. | 21:42 |
| fullermd | If I go in and maliciously change the content of some rev in a bzr history, then the SHA1 in the rev will no longer match and it'll scream bloody murder. | 21:42 |
| fullermd | That just means I have to change the SHA1 too. Then everything will look just fine. | 21:43 |
| fullermd | I can do the same thing in git too. The difference is, that since the SHA1 is the identifier, I'll be changing the identifier of the rev too, which means you're more likely to notice that it happened. | 21:43 |
| fullermd | So in git, you have that assurance, assuming you know what the revid was supposed to be. | 21:44 |
| fullermd | So if Linus tells you "hey, run rev 4bbc82ad2", you have [for practically, purposes, sufficiently] total assurance that you have what he meant. | 21:44 |
| PCJockey | fullermd: I realize it's just an arbitrary code, but why can't you...I guess I'm missing something. Too many distractions at the house right now to get my thoughts out clearly...:( | 21:44 |
| fullermd | Whereas if jelmer tells you to run revid jelmer@foo.bar-20110845183498 of bzr, that by itself doesn't prove that you have the same rev he meant. | 21:45 |
| fullermd | Since the identifier itself isn't the same thing as the integrity check. | 21:45 |
| fullermd | bzr's mechanism to do the same is PGP signing of revs, which conceptually gives you greater assurance. A number of practical issues present themselves with a little thought. | 21:46 |
| PCJockey | fullermd: I guess my point is that it seems there should be a way to solve the issue w/o using a hash as a commit id. | 21:46 |
| fullermd | Well, if I tell you what the hash is supposed to be too, you get the same. | 21:46 |
| fullermd | It's just that now, I have to give you TWO pieces of info (the revid and the hash). | 21:47 |
| fullermd | With the hash being the revid, you get both automatically any time things are referred to. | 21:47 |
| PCJockey | fullermd: I like everything I've read/seen about bzr up to now...but this seems like an issue to me. Maybe I'm worried about an improbability, but it does seem that over time data errors are likely...the issue is whether or not I'm giving it too much attention perhaps. | 21:51 |
| fullermd | Well, the way to protect against malice is PGP signing. That adds process burden. | 21:51 |
| PCJockey | fullermd: Yes, burden with benefit though...:) | 21:57 |
| fullermd | PGP signatures have the advantage that they're a lot more self-manifest than a hash. | 21:59 |
| fullermd | With a hash, you have to know what it's supposed to be for any rev you care about. With a signature, you just have to know what key you're expecting, then any rev with that key can be checked. | 22:00 |
| fullermd | The principal burden with PGP is tracking which keys are expected. I mean, I can make a key with your email on it and use it to sign things, so you'd have to somehow know which keys were really you authorizing stuff. | 22:01 |
| fullermd | Related is that you have to know it's supposed to be there. | 22:01 |
| fullermd | e.g., I make malicious changes to the rev, and the PGP verification will fail. I can't make a new signature with your key that'll pass. | 22:02 |
| fullermd | But I CAN just go ahead and throw away the signature wholesale. And then "verification" will pass just fine, since a rev with no signature can't fail a signature check. | 22:02 |
| PCJockey | fullermd: Yep. As, you said in the beginning...nothing is free...:) | 22:02 |
| fullermd | You'd have to know there was supposed to be one (either specifically, or by setting a hard requirement that EVERY rev be signed) to know something was up. | 22:03 |
| PCJockey | fullermd: Bzr is definitely has my attention now. The question is what will I do with it. How long have you been using it? Is there anything you'd like to see changed? | 22:04 |
| fullermd | I've been using it for... uh... a long time. Not too long after it first became publically available. | 22:04 |
| PCJockey | fullermd: I really appreciate you taking the time to talk this out with me! | 22:05 |
| fullermd | Jeez, more'n 6 years now. Wow. Hard to believe I've been largely CVS-free that long. I can still feel the scars... | 22:05 |
| fullermd | There are all sorts of things I'd like changed/fixed/etc. With me, that's pretty much a constant with any software ;> | 22:06 |
| fullermd | But I chose it because I liked it better than the other VCS choices at the time. Still using it because that decision still holds. | 22:06 |
| PCJockey | fullermd: I must admit I'm impressed by my 2nd look. I had looked in the past pre v2, but decided it wasn't mature enough to garner a further look. This time however, we're talking about the only thing I'm struggling with...and as you have pointed out, there is a work around if it matters that much to me...I just need to figure out what to do with it from here. I should probably install and then decide on experience versus theory. | 22:10 |
| fullermd | I've scrawled up some docs that may help you with the gestalt (not in security or internals so much, but what pieces you use and how they fit together). | 22:12 |
| fullermd | Not a substitute for the sort of intro tutorials that are out there, but I think they're a useful second step ("OK, I can follow this cookbook to do basic interactions, but I don't really understand just what the implications of all the things I do are") | 22:13 |
| fullermd | <http://wiki.bazaar.canonical.com/MatthewFuller/SpotDocs/PiecesInBrief> is intended to be a useful intro to the Repo/Branch/WT triumvirate, which underlies how everything in bzr works. | 22:14 |
| PCJockey | Great! Are they available online? | 22:14 |
| fullermd | (other stuff in SpotDocs talks about other things; if you're familiar with other DVCSen, you probably know a lot of it, but there's still some useful bits about how bzr deals with implications) | 22:15 |
| fullermd | They're pretty bottom-up, so it'll probably be pretty Greek without a little preceeding hands-on time experimenting with basic usage first. | 22:16 |
| fullermd | But IMAO it's necessary to understand those conceptual building blocks to be able to mentally model what various commands/messages/etc really mean, and so use things effectively. | 22:17 |
| fullermd | Or possibly I'm arrogant and full of crap. It's happened before. | 22:17 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!