log☇︎
78500+ entries in 0.567s
mod6: it sounds like everyone wants instead, a general overhaul to get to the 'wot variant press' instead, which would also fix the bug, because these vpatches, without a corresponding seal, would simply be ignored. ☟︎
mod6: i proposed a fix for mine. i think it was ultimiately rejected.
ben_vulpes: i'm changing diapers over here, it's a wonder that even asciilifeform can make sense of what i'm saying.
a111: Logged on 2016-12-22 01:40 ben_vulpes: 2) death()-ing on signatures for which a key does not exist in .wot
asciilifeform: a seal, on the other hand, floating about without an active pubkey, for for that matter without a corresponding patch, is inert.
mod6: i think, he's saying, what is the benefit of V honking when it doesn't find a key in your wot that matches a seal in your seal dir, provided that you don't pull a mod6.
asciilifeform: trinque: a patch, so long as there exists 1 seal for it, and that seal corresponds to a key in your active wot -- is valid.
asciilifeform: (it gets a temp dir jail)
ben_vulpes: let's rewind: what does trinque miss when v finds a seal for a vpatch for which it doesn't find a key and proceeds merrily, provided it does find *a* seal for the patch that corresponds to a key in .wot?
trinque: V is a harsh constraint upon the programmer that says that his acts will be unavoidably attributable to him, and those that vouched for him.
trinque: the thing is a political tool, and either does or does not acheive its desired effects
ben_vulpes: i will motherfucking *not* shuffle both patches/* and .wot/* around when i want to press. this is stupid and carves off a whole space of adjacent possible.
trinque: otherwise yes, asciilifeform is right that if this doesn't matter, just have a thing that presses patches with hashes in the m
a111: Logged on 2016-12-22 01:40 ben_vulpes: 2) death()-ing on signatures for which a key does not exist in .wot
asciilifeform: trinque: if you'd like to take a stab at a formal definition, i promise to read
phf: ^ a regrind of http://btcbase.org/patches/funken_prikey_tools ?
ben_vulpes: error, really. making a null set joke.
ben_vulpes: trinque: if all vpatches from genesis to HEAD carry a signature corresponding to a key in .wot, v presses. that signatures exist in .seals for people i don't choose to put the key for into .wot should not matter.
phf: well, since collective reaction is "tis but a scratch" i have nothing else to say, and will happily await mircea_popescu's unrate ☟︎
mod6: im just trying to minimize the warts a bit.
asciilifeform: i.e. the mechanism whereby you press a set for own consumption
asciilifeform: there is a 'harem-v' and a 'forum-v' ☟︎
phf: ben_vulpes: well, the point of V that has been celebrated is its ability to support a scientific dialog. you say something, i make a response, etc. this thread was literally about three different versions, one of them is stale, one of them is unreleased. there's not really an easy way to point to the line and say "oh this is what this does" etc. i claim that the source of this problem is fear. the genesis has to be perfect for all
ben_vulpes: i hold that exiting on discovery of a seal with no corresponding key in .wot puts an unnecessary burden on the operator to maintain system state.
mod6: And I'm happy to embark on a genesis once we resolve these current problems and the testing and review by lords is complete.
a111: Logged on 2016-01-24 03:21 mircea_popescu: to put it in you'll have to sign it. if it turns out later to have a hole, people will negrate you.
mod6: and who knows, imho, there's no gigantic rush to make a genesis for v. especially when we're still trying to work out how it should work.
asciilifeform: cost of failure, sometimes you simply live with. i signed FUCKGOATS, and it is a 'sapper makes 1 mistake' item, it is not possible to repair the units if i had made a mistake.
mod6: creating a genesis is a different thing too; v create a genesis of v. which i did work out, but alas, as you are eluding to, i never published because was nervous that it hadn't been very well audited yet.
trinque: but there is a place to do so, where there could be separation between the lab and the published-in-journal
trinque: V as conceived as a political weapon against the shitsucking github fuck does not work without the attribution the signatures provide
asciilifeform: i ended up turning that into a warning, vs fatal, but it looks like i never posted this variant. ☟︎
ben_vulpes: which i wrote before putting down a single line of code.
asciilifeform: iirc he a) fully understood how it behaves b) tendered no major objections
asciilifeform: ben_vulpes had a quite complete exposition on my original vtron
ben_vulpes: 2) death()-ing on signatures for which a key does not exist in .wot ☟︎☟︎
mod6: <+ben_vulpes> no, that's death() ing on a patch for which the system had valid seals, yours and mine. << this i dont agree with -- from a technical perspective. it looks to me that girl had "ascii and mod6" in .wot, and when it came across Mr. P.'s genesis .sig, it honked.
trinque: internal consistency is not a huge ask.
phf: ben_vulpes: this was a general comment, but the cost of failure is so high, simple things have become needlessly complicated.
ben_vulpes: no, that's death() ing on a patch for which the system had valid seals, yours and mine.
ben_vulpes: i'm pretty sure the design as described above is correct. the way i imagined this working in steady state is for patches and .seals to accumulate all of the patches and signatures thereof a user'd seen over all of history, and then the contents of .wot used to filter the patches and press used to pick a head.
mod6: what I should do, is ignore that sig, and continue iterating, collecting up all of the mod6 .sigs and then creating a v-tree from just those alone.
mod6: i could almost swear that we had a whole discussion on this before where we wanted it this way??
mod6: so mine, with only 'mod6' in .wot, calls death() when encountering a sig from a person not included in the wot.
mod6: so let's back up a minute, cause i'm still trying to figure out what I need to do here...
mircea_popescu: ben_vulpes> so long as there is at least one signature for a patch, for which signature v can import a corresponding key, on the basis of the wot, that patch should press. << ftfy.
mircea_popescu: i agree with the notion .wot is supposed to be a filter over .seals
ben_vulpes: so long as there is at least one signature for which v can import a corresponding key, that patch should press.
ben_vulpes: wot is a /filter/ on signature dir.
a111: Logged on 2016-12-22 00:52 mircea_popescu: the key being, that if you allow pressing without signatures, then git qualifies as a v implementation.
mircea_popescu: whereas if you allow dieing in arbitrary condition, then whatever, you get a more restrictive v than other people.
mircea_popescu: the key being, that if you allow pressing without signatures, then git qualifies as a v implementation. ☟︎
mircea_popescu: that it eschews key checks is one thing ; that it dies on which condition is apparently a different thing.
mircea_popescu: such as in "what classes of objections can or can't be brought to a v implementation"
asciilifeform: mod6: relax a bit. recall, my original vtron didn't even check hashes post-patch
mod6: which, is my fault for having a somewhat, apparently, limited grasp
asciilifeform: i'll point out that for so long as we have an agreed upon patch format, and can agree on a sigtron to use, with agreed pubkeys, 'each d00d has own vtron' worx fine
asciilifeform: at no point should the answer be a null set
asciilifeform: mircea_popescu: incidentally a vtron that has my 'origin' op, can check any tree for consistency simply by iterating over the files and running origin(hash_of_file)
mod6: this perhaps works as is, in a way.
mod6: we don't not allow the oppertunity to continue without a signature on a vpatch.
mod6: i think it's fine. you make a testkey, you sign your test vpatches, you press & test, etc. then we're using encryption everywhere. and we fail fast.
a111: Logged on 2016-12-22 00:03 mod6: Essentially, during the verify_signatures subroutine, if a vpatch is found to NOT have a corresponding signature, death().
asciilifeform: mircea_popescu: the current setup (with the patch.nickname.sig) is an artifact of the idiocy of pgp, where one cannot take the signature and extract a hash from it with which you can look up the patch from a manifest of patch hashes in O(NlogN)
asciilifeform: iterating over patches is O(N^2) (unless the files are correctly named, patch.nickname.sig, which we do, but imho is a bit of a cheat)
a111: Logged on 2016-12-22 00:03 mod6: Essentially, during the verify_signatures subroutine, if a vpatch is found to NOT have a corresponding signature, death().
a111: Logged on 2016-12-22 00:01 mircea_popescu: http://btcbase.org/log/2016-12-21#1587625 << you gotta appreciate scrutiny is very inelastic. many people used their own implementations ; discussion of others' versions only meaningfully starts after some localized familiarity etc. in any case "being qualified to even use v" is an iffy thing - seeing how it's a novel design, and the novelty is fundamental and conceptual, nobody is technically qualified to use one. you wouldn
asciilifeform: ly Mail itself doing the censoring.' << this is not a necessary hypothesis, swedish mitm could easily smooth out the response times (by slowing, or, alternatively, caching, the victim site)
asciilifeform: 'If there's a middlebox in the Swedish ISP side (theory 1), we should see that HTTP 302 responses come back much faster than HTTP 200 responses, because a hypothetical middlebox will sit between the Swedes and upstream, and therefore may respond much faster than upstream. If there is no middlebox (theory 2) we'd see comparable response times for HTTP 200 and HTTP 302. Of course, no middlebox implies quite strongly that it's the Dai
mod6: i need to dig into this a bit more, but the output flow is not necessarily the same order that the signature verification happens in.
mod6: Essentially, during the verify_signatures subroutine, if a vpatch is found to NOT have a corresponding signature, death(). ☟︎☟︎
mod6: So I have a bit of code that I've inserted that will do what you ask.
mircea_popescu: 't think you're an expert email or vim or bash user after less than a year and that's about how long v's been around.
mircea_popescu: http://btcbase.org/log/2016-12-21#1587625 << you gotta appreciate scrutiny is very inelastic. many people used their own implementations ; discussion of others' versions only meaningfully starts after some localized familiarity etc. in any case "being qualified to even use v" is an iffy thing - seeing how it's a novel design, and the novelty is fundamental and conceptual, nobody is technically qualified to use one. you wouldn ☝︎☟︎
pete_dushenski: it's going to be a very mauve 2017 isn't it
asciilifeform: http://btcbase.org/log/2016-12-21#1587616 << if everyone waited for asciilifeform in particular to do ~everything~, it will be a very sad world ☝︎
ben_vulpes: the other thing is separate and not precisely a problem, i mean to say.
ben_vulpes: no, this is separate and not exactly a problem anyways.
a111: Logged on 2016-12-21 20:44 mod6: <+asciilifeform> even the current thread in #mod6 , is possibly an example << asciilifeform found an oversight in my latest version of V. it doesn't have a flag allow or disallow the pressing of WILD vpatches.
mod6: <+ben_vulpes> http://btcbase.org/log/2016-12-21#1587516 << actually /i/ found it, and only when for personal lols i told it to do a thing that it shouldn't have << ah, right. ☝︎
a111: Logged on 2016-12-21 20:44 mod6: <+asciilifeform> even the current thread in #mod6 , is possibly an example << asciilifeform found an oversight in my latest version of V. it doesn't have a flag allow or disallow the pressing of WILD vpatches.
ben_vulpes: http://btcbase.org/log/2016-12-21#1587516 << actually /i/ found it, and only when for personal lols i told it to do a thing that it shouldn't have ☝︎
mod6: i feel like this thing is a moving target.
mod6: if i have a bunch of seals in my .seals dir from a guy named 'alf' that isn't in my wot, then V will complain.
mod6: i have a subroutine
jurov: wait a sec. mod6's build system won't work if v is to reject patches without sigs?
phf: that it might've been a bit premature to attempt to provide an authoritative comprehensive solution
phf: mod6: i think there's more infrastructure around V than there's V use, which leaves a lot of issues unexplored. for example there were mentions that V had a binary problem, but a serious discussion only happened recently, with no satisfactory solution. i think you were attempting to solve an important problem: how to let people outside of tmsr figure out build process without 6 months of log (seems like even more now), but i suspect
trinque: it's why V needs to be in a V tree itself.
mod6: you know, i'd like to. but my thing has been around for waaay to long for no one to have noticed a huge flaw.
mod6: I'm pretty sure i am a bozo.
asciilifeform: when v. belenko flew his mig to jp, and gave it as a gift to usa, su army ended up installing 'belenko switches' in all combat aircraft, supposedly.
asciilifeform: btw here's a related legend
asciilifeform: i can see mircea_popescu's 'this is a car with 4 brake pedals, wtf is wrong with you' argument.
trinque: how many encountered involve getting a thing to go down another branch
trinque: asciilifeform does exploitation for a living, right? or reversing exploits?
asciilifeform: mircea_popescu: this is not a pure win. for instance, some folx don't even ~keep~ a nonairgap signtron around. and now -- they would have to.
mircea_popescu: in the same way fuckjing an ugly broad is a use of your cock.
asciilifeform: how is a 'shitsign key' a 'use of cryptography' ?
phf: hmm, can make the process entirely painless with shitsign alias, that does --batch --quiet and uses a passwordless key