that might sound now, the history of OkCupid reaches farther back to
a pre-social-networking social networking site called SparkMatch, a
subsite of TheSpark, with roots in the fabled academic communities of
Harvard and MIT. Do with that what you will.
Cheers
___
Peter S. May
http://psmay.com/
Arsha Bertie wrote:
> i have been trying to run a script which encrypts and transfers files
> between 2 branches, i am using gpg for encryption, i have written a bash
> script and the script is working perfectly fine, but when i run it off a
> cron it doesnt want to work.
Are you also testing the
Casey Jones wrote:
> That's a clever way of dramatically increasing the "uniqueness" of each
> character to reduce the ambiguity of the OCR. It would be useful for
> both error detection and error correction. If it could be integrated
> into the OCR engine itself, it would be even more effective
Not meaning to kick a dead thread, but this whole conversation has
gotten me thinking about how to produce an effective variant of base64
for paper storage. Base64 is an interesting solution because it fully
encodes raw data into what is effectively printable characters. It was
yet obviously not
Andrew Berg wrote:
> In instances where GPG is used on a portable drive and used on
> different machines, it is much better to have gpg.conf read from the
> same directory as GPG rather than read from %appdata%\gnupg or
> ~/.gnupg. Just to have it check the same directory, then
> %appdata%\gnupg or
Peter Lebbing wrote:
> I want to have a text file with personal data in it, which I encrypt to
> myself, and decrypt to view and edit. However, to do that securely, I need
> an editor which will not leak the text in any way, so locking it's
pages in
> memory so they won't be swapped out, and other
Richard Hedlind wrote:
> My problem now is when I go to sign or encrypt my email I get the
> following error. "Send operation aborted. INV_RECP 0 0xC8D5E165 gpg
> command line and output: C:\\program file\\gnu\\gnupg\\gpg.exe
> --charset utf8 --batch --no tty -- status-fd2 --comments 'using gn
Charly Avital wrote:
> It *would seem* that it is gpg2 (not gpg) that does not support SHA224.
Confirmed. 1.4.7 and 2.0.3 (both from source) are also on my system.
$ (gpg --version; gpg2 --version) | grep 'Hash:'
Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Hash: MD5, SHA1, RIPEMD1
David Shaw wrote:
> Again, though, if you're going to actually code the passphrase into
> the script itself, why have a passphrase at all?
On this subject, you should also know that, if you can enter your
passphrase on the system once each time the system starts up, you may
find a combination of g
Sven Radde wrote:
> If yes, you're quite screwed as it will stay there forever: New contacts
> will not know which key to choose when they look your name up on the
> keyservers. People might be smart enough to use the newer of the two
> keys. If you don't rely so much on the keyservers to distribut
John B wrote:
> Somehow the other night I accidently imported a revoking thing for my main
> secret and public key pair when I was using kgpg. Kgpg tells me I need to
> un-revoke it in the manual editor, so, could someone tell me a quick and easy
> way to do so, please? Is it possible to un-re
Caught a couple of glitches. Ignore the previous version.
#!/bin/bash
umask 077
DIR=`mktemp -d`
PREFIX="packet-"
PREFIXPAT="$PREFIX*"
IFS=$'\n'
gpgsplit -p "$DIR/$PREFIX" "$@" <&0 &&
for i in $( find "$DIR" -name "$PREFIXPAT" ); do
if [ `echo -n "$i" | grep -cEe '-002[.]sig$'` != 0 ]; then
> All that said, yes, GPG has no way to delete designated revoker
> packets. The only way to do it is export your public key and run
> 'gpgsplit' on it. Then delete the packet you want to get rid of and
> 'cat' the packets back together.
See below for all the support for revoker removal that you
I had a workaround in mind that involved using multiple homedirs (one in
~/.gnupg and the other in ~/.backup-system2/crypto/gnupg) and then
spinning up one gpg-agent for each, using the first one's GPG_AGENT_INFO
in the normal shells and the other in the backup scripts only. To get
the passphrase
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
There are certainly some hacks you could try out, but they would be
somewhat error-prone. The easiest and most secure way to go about this
would probably be to --detach-sign instead of doing a cleartext signature.
If you require a cleartext signatu
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
I've extracted some Thawte and CAcert keys and certs from my browser and
imported them into gpgsm. ls -l ~/.gnupg/private-keys-v1.d/ lists the
three private keys that I imported, and all of the corresponding certs
show up in --list-keys:
$ gpgsm --
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Neglected to mention that the aforementioned problem was in gpgsm from
gnupg-2.0.3, with it and its four dependencies at latest release
versions, freshly compiled this weekend.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
Comment:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
In the stupid gpg-agent tricks department:
Say I have two signing keys. One of them signs e-mails and one of them
is used by an automated backup process; admittedly not as trustworthy
(which is why I don't want to use my e-mail key) but better than
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
> * Is there a user trustlist.txt that can be used instead, or do I need
> to edit trustlist.txt as root every time a change needs to be made?
I realize now this one was an RTFM. Problem was, I expected this
information in man gpgsm, not man gpg-ag
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On the one hand, yes, it was a gpg-agent problem. It turned out that
seahorse-daemon was running and screwing up the whole thing.
- --list-secret-keys started working once I unset GPG_AGENT_INFO. It
still complained that there was no gpg-agent runn
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
(This message is a dupe of one sent earlier under the wrong address;
admins, please deny the previous version.)
I've extracted some Thawte and CAcert keys and certs from my browser and
imported them into gpgsm (from gnupg-2.0.3, with it and all of i
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Henry Hertz Hobbit wrote:
> It is a worthwhile and at a much higher value than two cents, but I
> was NOT thinking of a new program. I was thinking of the magic number
> and the "file" command. Evidently, OpenPGP is totally incompatible
> with that an
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
My thinking is that this isn't so much a problem with packet formats as
general syntax. It sounds like you're trying to put two distinct
OpenPGP messages into the same file. The section "OpenPGP Messages"
(10.3 in RFC2440-bis-18) in the spec defines
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Henry Hertz Hobbit wrote:
> Even if you do have an encrypted file that doesn't use these,
> is there anything wrong with the file command returning the
> answers given for the first six bytes of the file? I can't
> find any information that they are u
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Johan Wevers wrote:
> Henry Hertz Hobbit wrote:
>
>> *3DES: 8C 0D 04 02 03 02
>> *CAST5: 8C 0D 04 03 03 02
>> *BLOWFISH: 8C 0D 04 04 03 02
>> *AES:8C 0D 04 07 03 02
>> *AES192: 8C 0D
I think I spotted a little error in libgcrypt's doc/gcrypt.info. Context
diff from 1.2.3 attached.
Thanks -- PSM
*** gcrypt.info 2006-08-28 06:07:08.0 -0400
--- gcrypt.info 2006-11-02 15:15:12.0 -0500
***
*** 1049,1055
AES (Rijndael) with a 128 bit key.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Patrick R. Dunbar wrote:
> Also is there any way to check if a gpg encrypted file is encrypted
> using AES?
Henry had some interesting answers, and his program does work for many
cases, but it's slightly ad-hoc and there are many valid possibilities
i
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Alex L. Mauer wrote:
> Peter S. May wrote:
>
>> I would think that it's important for keyservers to widely distribute
>> the revocation certificates of revoked signatures.
>
> Agreed. But it's not important to di
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Alex Mauer wrote:
> Is there any reason that the keyserver needs to continue to redistribute
> expired, revoked, or otherwise invalid (e.g. superseded) signatures?
>
> I can't think of any.
I would think that it's important for keyservers to widely d
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
David Shaw wrote:
> Please give enough information that we might be able to help you.
> Simply saying "keyserver uploads weren't working" gives us no way to
> even guess.
Since the problem was mentioned in the FAQ, I assumed this was the
problem at ha
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
My brother-in-law has just started using GnuPG for Windows (I think the
version in Gpg4win, but not sure). Until I reread the FAQ it was a bit
confusing that his keyserver uploads weren't working. It didn't readily
give him an error probably because
31 matches
Mail list logo
