290 entries in 0.64s
mod6: if I were him, this is what I would do: take the schematic blob, encode it, clearsign it with a note at the top and a hash of its output value. submit to deedbot. next, edit the code somewhere or prefereably create a README.txt that points to that deed, create a new fuckgoats_genesis.vpatch and fuckgoats_genesis.vpatch.alf
.sig on nosuchlabs.com, point to them with your www.
mod6: then this is a question for trinque; he'll know if deedbot can or can't deal with
.sig files.
mircea_popescu: asciilifeform t1 you publish K
.sign(hash(S)) ; time t2 you publish J
.sign(hash(S+S')) ; time t3 you publish S and S' thus proving J knew before everyone else.
mircea_popescu: J
.sign("Here's the laydown : 1. rsa got fucked, this is the process to exrtract privkey from pubkey ; 2. message so-and-so on deedbot was creating by so-hashing this salt and this pubkey ; 3. this here key J was created by using cryptoisystem ? with rng = privkey.K, which guarantees i am the one that made it ; 4. please use this here J' in future")
ben_vulpes: phf: that's my fault, uploaded a genesis.vpatch
.sig scriba: Logged on 2016-09-09: [00:55:24] <mod6> This hypothetical solution, even if it does work, wouldn't make it a one-button-push solution. Why? A person would need to get V + V
.sig, verify, create a .wot dir, sync the patches + seals, manually or automatically, press the tree, then navigate into the pressed tree, and then `make`.
mod6: <+mircea_popescu>
http://log.mkj.lt/trilema/20160909/#23 << yes mod6 but to clarify : "one button" refers to the situation where the user already has a trusted copy of V, and a
.sig directory populated as per his taste. these are part of the definition of identity, and going forward can and should be assumed present. << Sounds fair. Thanks for outlining this.
mircea_popescu: "who are you ?" "i am my V and
.sig machine" is a perfectly fine response.
scriba: Logged on 2016-09-09: [00:55:24] <mod6> This hypothetical solution, even if it does work, wouldn't make it a one-button-push solution. Why? A person would need to get V + V
.sig, verify, create a .wot dir, sync the patches + seals, manually or automatically, press the tree, then navigate into the pressed tree, and then `make`.
mircea_popescu:
http://log.mkj.lt/trilema/20160909/#23 << yes mod6 but to clarify : "one button" refers to the situation where the user already has a trusted copy of V, and a
.sig directory populated as per his taste. these are part of the definition of identity, and going forward can and should be assumed present.
mod6: This hypothetical solution, even if it does work, wouldn't make it a one-button-push solution. Why? A person would need to get V + V
.sig, verify, create a .wot dir, sync the patches + seals, manually or automatically, press the tree, then navigate into the pressed tree, and then `make`.
phf: asciilifeform: it's ffi, C-GPGME-OP-VERIFY on asciilifeform-kills-integer-retardation.vpatch.asciilifeform
.sig mod6: any one able to get their hands on: "URL: </pipermail/attachments/20160817/9a9f4612/attachment
.sig>" ?
jurov:
.sig always goes first
ben_vulpes: you can see that this is the issue you're running into if you run gpg --verify thinger.vpatch thinger.vpatch
.sig (or w/e the inane order is)
hanbot: so in V99995 testing, it'd seem the asciilifeform_add_verifyall_option.vpatch.asciilifeform
.sig is "invalid", i imagine 'cause of something to do with stan's old key? and deedbot only spits the current, which i have. i don't see the old one on btcalpha either, anyone have an idea fo' me?
☟︎ mrottenkolber: asciilifeform: But I get WARNING: asciilifeform-kills-integer-retardation.vpatch.asciilifeform
.sig is an INVALID seal for asciilifeform-kills-integer-retardation.vpatch !
mod6: ah, ok good deal shinohai. I updated the script so that it doens't even pull that
.sign file. we'll just rely on the sha512 that I hvae, alf has, and ben has.
mod6: take a look, i've removed 3 lines: 1. in the comment section where it lists PK's key fingerprint at the top 2. the curl that pulls the sign file for buildroot-2015.05.tar.gz
.sign 3. the gpg command that verifies buildroot-2015.05.tar.gz
.sign
ben_vulpes: my sha1 and md5 match those in k's
.sign
mod6: in here there seem to be
.sign files for the .tar.gz's, but they seem to have .gpg's for the tar.bz2's
ben_vulpes: mod6: while there's no harm in checking the
.sign, i don't know what it buys us
mod6: anyway, i guess i don't mind, i can add a part where we check the SHA1 & MD5 of the buildroot artifact and then continue to verify that
.sign file.
mod6: so with that build script, i'm thinking just take out the curl & --verify of that stupid
.sign file.
mod6: gernika: what happens if you're in the rotor dir and you do `gpg --verify buildroot-2015.05.tar.gz
.sign` ?
mod6: gernika: do you have this fine somewhere in your build env? buildroot-2015.05.tar.gz
.sign ?
assbot: Logged on 03-02-2016 18:52:30; phf: so there's two sig's that are not sha512. genesis.vpatch.trinque
.sig is sha256 and polarbeard_add_getpeerinfo_rpc.vpatch.polarbeard
.sig is sha1
mod6: yah, that's how my sigs look for v.pl: v.pl.mod6
.sig phf: so there's two sig's that are not sha512. genesis.vpatch.trinque
.sig is sha256 and polarbeard_add_getpeerinfo_rpc.vpatch.polarbeard
.sig is sha1
☟︎ polarbeard: still don't see how we can't have author_file_unixtime.vpatch and author_file_unixtime.vpatch.author
.sig mircea_popescu: polarbeard_add_getpeerinfo_rpc.vpatch and polarbeard_add_getpeerinfo_rpc.vpatch.mircea_popescu
.sig in this order
jurov: or should i figure how to shoehorn .vpatch+ .vpatch
.sig to dpaste?
trinque: jurov │ trinque: does deedbot allow submissions with detached signatures? like "deedbot- <url1
.sig> <url2>" << it does not, but is not rocket surgery to add. seems useful for posting scripts
jurov: trinque: does deedbot allow submissions with detached signatures? like "deedbot- <url1
.sig> <url2>"
mod6: asciilifeform: what was interesting on these ones is that not only idn't they contain *.vpatch.asciilifeform
.sig -- they were: *.vpatch.asc
mod6: gpg --verify buildroot-2015.05.tar.gz
.sign
mod6: asciilifeform_malleus_mikehearnificarum.vpatch.asciilifeform
.sig mod6: asciilifeform-programmable-versionstring.vpatch.asciilifeform
.sig mod6: Name: asciilifeform-programmable-versionstring.vpatch
.sig mod6: Name: asciilifeform_malleus_mikehearnificarum.vpatch
.sig mod6: mv asciilifeform-programmable-versionstring.vpatch
.sig asciilifeform-programmable-versionstring.vpatch.asciilifeform
.sig mod6: mv asciilifeform_malleus_mikehearnificarum.vpatch
.sig asciilifeform_malleus_mikehearnificarum.vpatch.asciilifeform
.sig mod6: any way the real sig name is currently "bitcoin-asciilifeform.1.vpatch.mod6
.sig" not <+jurov> only the question what is the '1' in bitcoin-asciilifeform.1.mod6.vpatch
.sig doing there
jurov: only the question what is the '1' in bitcoin-asciilifeform.1.mod6.vpatch
.sig doing there
PeterL: should have patch.vpatch and patch.vpatch
.SIGNER1
.sig and patch.vpatch
.SIGNER2
.sig ?
ascii_butugychag: the .asciilifeform
.sig IMMEDIATELY tells you that asciilifeform signed the thing before the .
jurov: instead of *.vpatch.*
.sig you have *.vpatch
.sig filenames which are a bit easier to work with
jurov: it would be 'asciilifeform_tx-orphanage_amputation.mod6.vpatch
.sig'
jurov: bitcoin-asciilifeform.1.mod6.vpatch
.sig ascii_butugychag: let's start with 'asciilifeform_tx-orphanage_amputation.vpatch.mod6
.sig'
jurov: i want filename.vpatch that i can just take and slap
.sig in the end of it to find a signature
jurov: i just have some random bunch of name.vpatvh and somethingother
.sig someone sends by email
ascii_butugychag: patchname in 'patchname.vpatch' must equal patchname in patchname
.signer
.sig jurov: no it maps to patchname.vpatch.<unknown>
.sig ascii_butugychag: jurov: it doesn't need even now. what is your problem with patchname
.signer
.sig ?
jurov: authorname:patchname:signername.vpatch
.sig ascii_butugychag: jurov: theoretically you can avoid using the name prior to
.sig, but then you have to check ALL seals agains ALL patches ALWAYS and this is O(N^2)
☟︎ jurov: so imma have a regex like ([^_]+)_.*?\.vpatch\.(.*?)\
.sig to find out something to feed to v?
mod6: which, i think is fine because then i can sign that patch and call it: asciilifeform-kills-integer-retardation.vpatch.mod6
.sig mod6: so i was wrong above, not just
.sig, but <vpatch_name>.vpatch.<wot_id>
.sig jurov: one is .anything , the other one .anything
.sig mod6: i.e.: asciilifeform-kills-integer-retardation.vpatch && asciilifeform-kills-integer-retardation.vpatch.asciilifeform
.sig mod6: <+jurov> oh when i see it: trinque and everyone, pls send detached signatures as <name>
.sig << for V to work properly the sigfiles (seals) need to be named the same as the vpatch filename with a
.sig on the end. is that what you're saying?
jurov: oh when i see it: trinque and everyone, pls send detached signatures as <name>
.sig phf: contributors. an obvious next step is to have a gpg --verify buildroot
.sig rely on the contents of .wot folder, by, for example, making a temp directory, doing a for pubkey in .wot/*.asc; do gpg --homedir $tmpdir --import $pubkey; done, then doing gpg --homedir $tmpdir --verify foo
.sig; then rm -rf $tmpdir. this way a .wot folder is a canonical source of pubkeys always and for all operations
danielpbarron: WARNING: asciilifeform-kills-integer-retardation.vpatch.asciilifeform
.sig is an INVALID seal for asciilifeform-kills-integer-retardation.vpatch!
mircea_popescu: WARNING: genesis.vpatch.mircea_popescu
.sig is an INVALID seal for genesis.vpatch!
ben_vulpes: go, `mkdir /tmp/badsigs/; touch /tmp/badsigs/{1,2,3}
.sig; gpg --verify-files /tmp/badsigs/*`
lobbes: ascii_field: I *was* able to verify mpi-genesis.tar.gz
.sig (downloaded from IE); yet to diff with wget version