log☇︎
290 entries in 0.712s
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.
asciilifeform: in other lulz, yet another honeypot, https://www.sigaint.org/incidents.html
asciilifeform: phf: i have: 1) fg-genesis.vdiff 2) fg-genesis.vdiff.asciilifeform.sig
asciilifeform: phf et al: http://www.loper-os.org/pub/lam-par/lam-par-genesis.vpatch and http://www.loper-os.org/pub/lam-par/lam-par-genesis.vpatch.asciilifeform.sig have been reground. again.
asciilifeform: mod6 et al: http://www.loper-os.org/pub/lam-par/lam-par-genesis.vpatch and http://www.loper-os.org/pub/lam-par/lam-par-genesis.vpatch.asciilifeform.sig have been reground. thx to mod6's eagle eye.
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.
asciilifeform: J.sign can sign anything anyone likes once J is known.
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`.
asciilifeform: same .vpatch.sig, vpatch, key --- what does gpg from command line output ?
phf: asciilifeform: it's ffi, C-GPGME-OP-VERIFY on asciilifeform-kills-integer-retardation.vpatch.asciilifeform.sig
asciilifeform: http://www.loper-os.org/pub/mpi/mpi_second_cut.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? ☟︎
Framedragger: uncompressed TXTs as well as signatures (as separate *.sig's) in http://95.85.10.71:8000/47/ and http://95.85.10.71:8000/31/
shinohai: curl -F 'vpatch=@foo.vpatch' -F 'seal=@bar.sig' http://btcbase.org/upload <<< neat!
mrottenkolber: asciilifeform: But I get WARNING: asciilifeform-kills-integer-retardation.vpatch.asciilifeform.sig is an INVALID seal for asciilifeform-kills-integer-retardation.vpatch !
asciilifeform: gpg --verify some.vpatch.sig
asciilifeform: hdbuck: yours barfs on line 45, gpg --verify buildroot-2015.05.tar.gz.sign ?
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.
phf: mod6: that signature is busted, just vidy output of curl -s http://buildroot.uclibc.org/downloads/buildroot-2015.05.tar.gz.sign
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 12-02-2016 14:13:21; polarbeard: works like a charm, here is a patch for removing some unused functions if somebody is interested: https://github.com/polarbeard/trb/blob/master/patches/polarbeard_rm_unused_functions.vpatch https://github.com/polarbeard/trb/blob/master/sigs/polarbeard_rm_unused_functions.vpatch.polarbeard.sig
assbot: trb/polarbeard_rm_unused_functions.vpatch.polarbeard.sig at master · polarbeard/trb · GitHub ... ( http://bit.ly/1PrehPK )
polarbeard: works like a charm, here is a patch for removing some unused functions if somebody is interested: https://github.com/polarbeard/trb/blob/master/patches/polarbeard_rm_unused_functions.vpatch https://github.com/polarbeard/trb/blob/master/sigs/polarbeard_rm_unused_functions.vpatch.polarbeard.sig ☟︎
polarbeard: https://raw.githubusercontent.com/polarbeard/trb/master/sigs/polarbeard_add_sendrawtransaction_rpc.vpatch.polarbeard.sig
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
mircea_popescu: http://log.bitcoin-assets.com/?date=03-02-2016#1395431 << i dunno that i renamed anything when signing it. i thought thatg's how we do it, i take the original v.pl and turn it into v.pl.me.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?
ascii_butugychag: how about !patch PATCH.vpatch SIG.somebody.sig
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 ?
ascii_butugychag: using the .name.sig convention
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
assbot: Logged on 15-08-2015 22:32:03; trinque: shinohai: http://deedbot.org/genbootstrap.sh.sig
BingoBoingo: http://ftp.openbsd.org/pub/OpenBSD/patches/5.7/common/022_ssh.patch.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
thestringpuller: + gpg --verify buildroot-2015.05.tar.gz.sign
danielpbarron: WARNING: asciilifeform-kills-integer-retardation.vpatch.asciilifeform.sig is an INVALID seal for asciilifeform-kills-integer-retardation.vpatch!
mircea_popescu: toolchain/ v_users_manual.txt.mod6.sig
mircea_popescu: rotor.tar.gz.sig v_quick_start.txt.mod6.sig
mircea_popescu: buildroot-2015.05.tar.gz.sign v.pl.mod6.sig
mircea_popescu: ../ V-20151129.tar.gz.mod6.sig
mircea_popescu: WARNING: genesis.vpatch.mircea_popescu.sig is an INVALID seal for genesis.vpatch!
mircea_popescu: http://thebitcoin.foundation/v/V-20151129.tar.gz.mod6.sig << correct url
mircea_popescu: http://thebitcoin.foundation/v/V-20151108.tar.gz.mod6.sig << da fuyck ?
assbot: Logged on 29-11-2015 20:51:01; mod6: All: Version '99997 K' of V has been posted to ML & website: http://thebitcoin.foundation/v/V-20151129.tar.gz && http://thebitcoin.foundation/v/V-20151129.tar.gz.mod6.sig
mod6: All: Version '99997 K' of V has been posted to ML & website: http://thebitcoin.foundation/v/V-20151129.tar.gz && http://thebitcoin.foundation/v/V-20151129.tar.gz.mod6.sig ☟︎
ben_vulpes: go, `mkdir /tmp/badsigs/; touch /tmp/badsigs/{1,2,3}.sig; gpg --verify-files /tmp/badsigs/*`
assbot: Logged on 02-11-2015 19:05:41; ascii_field: does anyone else find that http://www.loper-os.org/pub/mpi/mpi.tar.gz.sig will NOT download in any ver of firefox ?
lobbes: ascii_field: I *was* able to verify mpi-genesis.tar.gz.sig (downloaded from IE); yet to diff with wget version