On Sun, Feb 12, 2006 at 04:45:33PM +, Ben Laurie wrote:
Werner Koch wrote:
On Sat, 11 Feb 2006 12:36:52 +0100, Simon Josefsson said:
1) It invoke exit, as you have noticed. While this only happen
in extreme and fatal situations, and not during runtime,
it is not that
On Mon, Feb 13, 2006 at 11:29:00AM +0100, Simon Josefsson wrote:
However, looking at the code, it is possible for Postfix to handle
this. They could have installed a log handler with libgcrypt, and
make sure to shut down gracefully if the log level is FATAL. The
recommendation to avoid
On Tue, Feb 14, 2006 at 03:24:09AM +1300, Peter Gutmann wrote:
1. There are a great many special-case situations where no published protocol
fits. As the author of a crypto toolkit, I could give you a list as long
as your arm of user situations where no existing protocol can be applied
On 2/13/06, Peter Gutmann [EMAIL PROTECTED] wrote:
I would expect that typically implementors would be following a published
standard, which would (well, one would hope) have had expert cryptographers
check it over sometime prior to publication
Published implementations aren't immune to
* Werner Koch:
On Sat, 11 Feb 2006 12:36:52 +0100, Simon Josefsson said:
1) It invoke exit, as you have noticed. While this only happen
in extreme and fatal situations, and not during runtime,
it is not that serious. Yet, I agree it is poor design to
do this in a library.
On Sun, 12 Feb 2006 19:33:07 -0800 (PST), David Wagner said:
Of course, it would be better for a crypto library to document this
assumption explicitly than to leave it up to users to discover it the
hard way, but I would not agree with the suggestion that this exit before
Actually libgcrypt
On Sun, 12 Feb 2006 23:57:42 -, Dave Korn said:
:-) Then what was EINVAL invented for?
[ Then for what was assert invented for? ]
Really it's never ok for anything, not even games, and any program that
fails to check error return values is simply not properly coded, full stop.
I
On Mon, 13 Feb 2006 11:29:00 +0100, Simon Josefsson said:
That /dev/random doesn't exist seem like a quite possible state to me.
Running Linux this is not possible because /dev/random is guarenteed
to be available.
Further, a library is not in a good position to report errors. A
users will
On Mon, 13 Feb 2006 03:07:26 -0500, John Denker said:
That might lead to an argument in favor of exceptions instead of error
codes, along the following lines:
-- Naive code doesn't catch the exception. However (unlike returned
error codes) this does not cause the exception to be lost.
| I disagree strongly here. Any code which detects an impossible state
| or an error clearly due to a programming error by the caller should
| die as soon as possible.
|
| That is a remarkably unprofessional suggestion. I hope the people
| who write software for autopilots, pacemakers,
http://www.firingsquad.com/hardware/ati_nvidia_hdcp_support/
HDCP is Intel-designed copy prevention that uses strong crypto to
encrypt the digital video signal on the cable between your video card
(or TV or DVD player) and your monitor. There is no need for it --
you are seeing the signal that
--
Werner Koch retorted:
I disagree strongly here. Any code which detects an impossible
state or an error clearly due to a programming error by the caller
should die as soon as possible.
John Denker wrote:
That is a remarkably unprofessional suggestion. I hope the people
who
--
Libgcrypt tries to minimize these coding errors; for example there
are no error returns for the RNG - if one calls for 16 bytes of
random one can be sure that the buffer is filled with 16 bytes of
random. Now, if the environment is not okay and Libgcrypt can't
produce that random - what
I don't believe MtE is good advice, and I have yet to see a decent reason
why one would want to use that instead of EtM.
Of course when we talk about EtM, the MAC should be applied over all
plaintext headers and trailers (including IV used for encryption, algorithm
identifier, protocol version,
On Tue, Feb 14, 2006 at 12:44:39PM +1000, James A. Donald wrote:
Absent exception handling, mission critical tasks should have no
exceptions, which is best accomplished by the die-on-error standard.
Absent good library design, the developer's goals are best accomplished
with the
In message [EMAIL PROTECTED], James A. Donald writes:
--
Libgcrypt tries to minimize these coding errors; for example there
are no error returns for the RNG - if one calls for 16 bytes of
random one can be sure that the buffer is filled with 16 bytes of
random. Now, if the environment
16 matches
Mail list logo
