tmsr - Search: gpgme

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

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: 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

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: i thought gpgme spawns a child process and keeps it around. still pushing all that data around is expensive..

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.”

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)

FabianB: gpgme is a library for gpg, gpg-agent just just 'remember my pw for a period of time'

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...