log☇︎
49 entries in 1.15s
mircea_popescu: pecl = "php extensions", basically looks like some sort of fancy callout system. and yes, here to gpgme
spyked: only one reason: brevity. had I solved this, then I would also have to solve "GPG error codes" and all the other problems that GPGME solves. the point was to avoid this complexity altogether for what I'm doing.
phf: gpgme doesn't tell you if original was armored, so requires a separate check (in before gpgme is evil), it does tell you everything about untrusted keys and source and such
a111: 44 results for "gpgme", http://btcbase.org/log-search?q=gpgme
asciilifeform: !#s gpgme
phf: recent gpgme doesn't build with gnupg@1.4 out of the box
phf: come to think of it sybil is not the right word in this case, on application level there's no psuedonymity and you only talk to people in wot. on transport level an attacker can construct a valid looking (struct layout wise) pgp packet, which in my naive spec implementation is handed over to gnupg. now you have a bunch of potential attack vectors here, but assuming there's no memory attacks in gnupg, race conditions in gpgme,
phf: asciilifeform: unfortunately nothing exciting, i had a stale gpgme ctx
phf: asciilifeform: it's ffi, C-GPGME-OP-VERIFY on asciilifeform-kills-integer-retardation.vpatch.asciilifeform.sig
phf: i figured, but i suspect it's a much more mundate explanation. nothing's change in gpg/gpgme setup from the previous core, so this must be something novel in the way cmucl is packing itself to a core file, or perhaps it's not reloading those foreign libs properly ☟︎
phf: i wouldn't be surprised if somebody sets safety 0, that's something that i should actually grep for, but i think it's gpgme that's doing it
asciilifeform: also gpgme sucked donkey ballz in every conceivable other way.
phf: gpgme in homebrew goes out of its way to build with gpg2 with that same mantra that tech wreckers use everywhere, it's deprecated. don't question it, morty, it's deprecated. the community deprecated it. yep.
phf: alexandria cffi flexi-streams net-telent-date trivial-features usocket araneida cl-irc gpg-error rfc2388 trivial-gray-streams v babel defservice gpgme split-sequence uiop
phf: favorite gpgme error, "err-no-error"
phf: quoted 14s is from my graph thing, and im using gpgme
asciilifeform: phf: i don't recall anybody using gpgme here
phf: i thought gpgme spawns a child process and keeps it around. still pushing all that data around is expensive..
phf: if i have a gpgme key instance, is there some way to patch its trust level?
phf: i have that patched gpgme version though, can always punt into the ugly land. i'm going to tackle diff first though, seems like a significant hole in my algo knowledge
assbot: Logged on 28-11-2015 20:29:36; phf: so gossip should be able to accept variable size packets, a naive version is to have our own header, {headerbit,body size} followed by body. in case of gpg backend we feed body to gpgme, let it figure things out. a better option is to have a (rudimentary?) parser for opengpg packets, and only accept a fixed subset of packet sequences, or specifically what you get when you encrypt a message with gpg. {pubkey enc
ascii_field: http://log.bitcoin-assets.com/?date=28-11-2015#1333229 << for gossipd, using stock gpg, much less an abomination (time the invocations some time..!) like gpgme, is a monumentally bad idea ☝︎
phf: so gossip should be able to accept variable size packets, a naive version is to have our own header, {headerbit,body size} followed by body. in case of gpg backend we feed body to gpgme, let it figure things out. a better option is to have a (rudimentary?) parser for opengpg packets, and only accept a fixed subset of packet sequences, or specifically what you get when you encrypt a message with gpg. {pubkey enc packet}{encrypted data ☟︎
phf: asciilifeform: you were right re gossip prototype in common lisp. it was a needless distraction, i spent a long time getting lisp gpgme bindings working, and the end result was still pos. i'll just send the patches to gnupg ml, and maybe they'll update upstream, but that's not gotten me anywhere closer. i learned that cffi is mostly a mess. (someone worked some improvements on cffi recently, which resulted in cffi documentation being
phf: asciilifeform: gpgme doesn't exactly "calls out", it talks to gpg via a text protocol, but i agree with your overall point. gossip has a fixed set of crypto operations, that can be abstracted, until you finish your crypto state machine gizmo.
phf: support of gpgme. the bindings come standard with gpgme release, but what's there was not updated since 2008. officially artifex is still working on that, but i take it nobody's heard from him in a while?
phf: gpgme bindings are broken, since they've not been updated since 2008 or so, i'm surprised they are in the source tree at all
ben_vulpes: phf: where's a sane place from which to procure gpg-error? i've found some text files scattered about the web but nothing in the gpgme lang/cl dir
phf: huh, libgpg-error and gpgme come with common lisp bindings (and only cl) in the standard distribution..
phf: This has been frequently requested. However, the current viewpoint of the GnuPG maintainers is that this would lead to several security issues and will therefore not be implemented in the foreseeable future. However, for some areas of application gpgme could do the trick.”
mike_c: going to give gpgme a run around the block and see how that does.
davout: mike_c: i got gpgme to work fine fwiw
mike_c: gpgme i don't know about
asciilifeform: mike_c: gpgme is a wrapper for gpg !!
punkman: python-gpgme doesn't call out to shell but I haven't used it
punkman: though nobody uses gpgme so I'm wary
punkman: there's also python-gpgme that skips the "pipe to shell" retardation
Hasimir: it's currently in a branch of git.gnupg.org/gpgme (to be merged with master when I finish cleaning up the last of the ancient examples)
Hasimir: I ported the python bindings for gpgme to py3
dignork: Mats_cd03 gpgme is just a wrapper, executing gpg and reading stdout/feeding stdin
FabianB: Mats_cd03: http://lists.gnupg.org/pipermail/gnupg-devel/2014-May/028483.html <-- not so long ago (GPGME 1.5.0 released)
FabianB: gpgme
Mats_cd03: gpgme doesnt seem to be updated anymore
bounce: sure. mutt doesn't use gpgme either, IIRC
FabianB: gpgme is a library for gpg, gpg-agent just just 'remember my pw for a period of time'
mircea_popescu: gpgme isn't bad, there's also a gpgagent thing that seems solid
FabianB: pympex and MPEx.rb use gpgme
bounce: interfacing gpg is clunky to the point there's a library to make it easier, gpgme (haven't checked how much it helps, to me it's just another annoying dependency), though some programs just run the commands and look at the answer strings
gabridome: FabianB: I've succeded to compile it with the new version of Xcode!!! Now it gives me errors about No definition for rb_s_gpgme* maybe is the ruby version...