On Tue, 11 Jul 2006 20:16, Tony Whitmore said:
Is there a compatibility list of drivers supported by GPG's internal
card reader driver, other than the relevant part of the HOWTO? Do
No there is no such list. This is becuase the driver implements the
CCID specification with a few limitations
Hi folks.
I've read the man page. I've read the FAQ's. I'm not seeing what I'm
looking for.
Using something like zip, you can use a -T to test the integrity of
the file. Note: this is not testing that nobody has altered it, or that
it came from a specific user; it is only testing whether it
On Wed, Jul 12, 2006 at 09:05:58AM +0200, Werner Koch wrote:
On Tue, 11 Jul 2006 20:16, Tony Whitmore said:
Is there a compatibility list of drivers supported by GPG's internal
card reader driver, other than the relevant part of the HOWTO? Do
No there is no such list. This is becuase
Benny Helms wrote:
I'm looking for a way to gpg encrypt a file, test that the encryption
was good and that the file can be extracted, and then to delete the
original file.
Forgive a silly question, but what's wrong with decrypting the file as a
way of verifying the encryption worked?
At the
On Tue, Jul 11, 2006 at 10:03:20PM +0100, Tony Whitmore wrote:
I'm running Ubuntu Dapper. Am I right in thinking the entries in
/proc/bus/usb/XXX/XXX should be modified to match the rules (i.e. group
scard, mode 644)? Because they don't seem to be:
Current systems with udev should use
On Tue, Jul 11, 2006 at 01:38:23PM -0600, Benny Helms wrote:
Hi folks.
I've read the man page. I've read the FAQ's. I'm not seeing what I'm
looking for.
Using something like zip, you can use a -T to test the integrity of
the file. Note: this is not testing that nobody has altered it,
On Wed, Jul 12, 2006 at 12:02:12PM +0100, Mark Brown wrote:
On Tue, Jul 11, 2006 at 10:03:20PM +0100, Tony Whitmore wrote:
I'm running Ubuntu Dapper. Am I right in thinking the entries in
/proc/bus/usb/XXX/XXX should be modified to match the rules (i.e. group
scard, mode 644)? Because
On Wed, 2006-07-12 at 12:25 +0200, Janusz A. Urbanowicz wrote:
On Tue, Jul 11, 2006 at 01:38:23PM -0600, Benny Helms wrote:
snip
What is your actual threat model here?
The simplest answer is to check gpg's rc after the encryption run.
Before deleting original file, I must make certain
On Wed, 2006-07-12 at 05:14 -0500, Robert J. Hansen wrote:
Benny Helms wrote:
I'm looking for a way to gpg encrypt a file, test that the encryption
was good and that the file can be extracted, and then to delete the
original file.
Forgive a silly question, but what's wrong with
On Wed, 2006-07-12 at 13:23 -0400, Mark Hardman wrote:
If you're using bash, can't you just script it like this...
1. encrypt to gpg
2. decrypt to text (or whatever it was originally) with altered file
name (filename.test_decrypt)
3. do a diff between the original file and the newly
On Wed, Jul 12, 2006 at 11:57:21AM -0600, Benny Helms wrote:
On Wed, 2006-07-12 at 13:23 -0400, Mark Hardman wrote:
If you're using bash, can't you just script it like this...
1. encrypt to gpg
2. decrypt to text (or whatever it was originally) with altered file
name
There is no way to design such a self-check. This isn't a lack in
GnuPG, but a design impossibility for any program. Think about it: a
check mode would try and account for a bug in GnuPG and warn you
that the file was not encrypted properly. However, if you're
presuming a bug, then who says
Benny Helms wrote:
snippage
First off, I hope you've considered that gpg is doing what it's suppose
to do and you're really trying to break it. If your encrypted files
are corrupt at a later date, maybe you have another problem and don't
*want* to make it just go away. IOW, be cautious that a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jonathan Rockway wrote:
BTW, why are you encrypting these files anyway? If someone broke into
your computer they could just steal the crypto key too.
True, unless the private key isn't kept on the same machine. Which
also would negate the
On Wed, 2006-07-12 at 13:11 -0500, Jonathan Rockway wrote:
snip
BTW, why are you encrypting these files anyway? If someone broke into
your computer they could just steal the crypto key too.
Excellent question! Truth be told, as soon as they are encrypted,
they're being moved to another
On Wed, 2006-07-12 at 15:13 -0400, Jeffrey F. Bloss wrote:
Benny Helms wrote:
snippage
Don't know if this will help or not, but I just did a quick test with
GnuPG 1.4.4 and the --dry-run command line switch seem to work fine.
Outputs to stdout rather than writing a file to disk. I changed
This might be a hard one.
When you encrypt to a public key, there is no way gpg
can decrypt it, to verify that it can be decrypted,
unless it can unlock the private key with your password.
The only way i see, is that gpg would have to encrypt 2 times
and compare the results. But then again, the
Benny Helms wrote:
On Wed, 2006-07-12 at 15:13 -0400, Jeffrey F. Bloss wrote:
Benny Helms wrote:
snippage
Don't know if this will help or not, but I just did a quick test with
GnuPG 1.4.4 and the --dry-run command line switch seem to work fine.
Outputs to stdout rather than writing a file
18 matches
Mail list logo
