On 04/04/18 01:09, Christos Zoulas wrote:
> In article <20180403220010.ga5...@britannica.bec.de>,
> Joerg Sonnenberger wrote:
>> This is not a very useful commit message...
>
> I was typing the same thing :-)
Sorry, I was thinking in the context of the netpgp history (the PR was
handled previ
In article <20180403220010.ga5...@britannica.bec.de>,
Joerg Sonnenberger wrote:
>On Tue, Apr 03, 2018 at 09:57:15PM +, Sevan Janiyan wrote:
>> Module Name: src
>> Committed By:sevan
>> Date:Tue Apr 3 21:57:15 UTC 2018
>>
>> Modified Files:
>> src/crypto/external
On Tue, Apr 03, 2018 at 09:57:15PM +, Sevan Janiyan wrote:
> Module Name: src
> Committed By: sevan
> Date: Tue Apr 3 21:57:15 UTC 2018
>
> Modified Files:
> src/crypto/external/bsd/netpgp/dist/src/lib: libnetpgp.3
> src/crypto/external/bsd/netpgp/dist/src/libbn: libnetpg
In article <20180401232528.1e523f...@cvs.netbsd.org>,
Sevan Janiyan wrote:
>-=-=-=-=-=-
>
>Module Name: src
>Committed By: sevan
>Date: Sun Apr 1 23:25:28 UTC 2018
>
>Modified Files:
> src/crypto/external/bsd/netpgp/dist/src/lib: libnetpgp.3
>
>Log Message:
>netpgp_t is a struct
Hey,
On 20/02/2017 03:40, Alistair Crooks wrote:
Thanks, but I'd really like it if netpgp would work the same on all
pkgsrc platforms:
The linux man page for getpass(3) (https://linux.die.net/man/3/getpass)
says:
The function *getpass*() returns a pointer to a static bu
Thanks, but I'd really like it if netpgp would work the same on all pkgsrc
platforms:
The linux man page for getpass(3) (https://linux.die.net/man/3/getpass)
says:
The function *getpass*() returns a pointer to a static buffer containing
(the first *PASS_MAX* bytes of) the password without the tra
On Jul,Thursday 21 2011, at 8:15 PM, Martin Husemann wrote:
> On Thu, Jul 21, 2011 at 10:45:55AM -0700, Jeff Rizzo wrote:
>> I believe this is a general gdb complaint, not specific to atf. I've
>> run into this issue as well - there are some workarounds (threaded
>> debugging works somewhat on
On Thu, Jul 21, 2011 at 10:45:55AM -0700, Jeff Rizzo wrote:
> I believe this is a general gdb complaint, not specific to atf. I've
> run into this issue as well - there are some workarounds (threaded
> debugging works somewhat on core dumps), but it's a giant pain given
> than one of the key co
On 7/21/11 10:33 AM, Julio Merino wrote:
On 7/21/11 4:49 AM, Martin Husemann wrote:
However, from my very practical experience (from all relevant sides:
running
tests, writing/extending them, and most importantly: fixing the troubles
they show) it is not the framework that causes most problems
On 7/21/11 2:11 AM, Iain Hibbert wrote:
PS the "predictable consequence" that you cannot fold in external test
programs did not come true, see tests/lib/libevent/t_event.sh for example,
though I note that the number of libevent tests are misrepresented in the
atf-total since the test program prin
On 7/21/11 4:49 AM, Martin Husemann wrote:
On Thu, Jul 21, 2011 at 07:11:56AM +0100, Iain Hibbert wrote:
I thought that I agreed with Jukka, it seemed to be a complaint with no
specific content except that you were uncomfortable (unfamilar?) with
atf.
I'm mostly with Iain here, though I have a
On 7/20/11 10:35 PM, David Holland wrote:
On Wed, Jul 20, 2011 at 12:49:34PM +0300, Jukka Ruohonen wrote:
> A lot of empty talk here.
>
> What is exactly your problem?
You asked, I tried to explain, you describe it as "empty talk". What
are you expecting, a gigantic patch?
Anyway, I gue
On Thu, Jul 21, 2011 at 07:11:56AM +0100, Iain Hibbert wrote:
> So, what exactly is your problem? I don't understand your complaint that
> "atf is too intrusive"; it is a test framework and all the code that it
> runs is written to automatically run within that framework.. also, the
> pretty repo
On Thu, Jul 21, 2011 at 07:11:56AM +0100, Iain Hibbert wrote:
> I thought that I agreed with Jukka, it seemed to be a complaint with no
> specific content except that you were uncomfortable (unfamilar?) with
> atf.
I'm mostly with Iain here, though I have a vague idea and think I partly
understan
On Thu, 21 Jul 2011, David Holland wrote:
> On Wed, Jul 20, 2011 at 12:49:34PM +0300, Jukka Ruohonen wrote:
> > A lot of empty talk here.
> >
> > What is exactly your problem?
>
> You asked, I tried to explain, you describe it as "empty talk". What
> are you expecting, a gigantic patch?
I thou
On Wed, Jul 20, 2011 at 12:49:34PM +0300, Jukka Ruohonen wrote:
> A lot of empty talk here.
>
> What is exactly your problem?
You asked, I tried to explain, you describe it as "empty talk". What
are you expecting, a gigantic patch?
Anyway, I guess this about sums it up: the real problem is ap
On Wed, Jul 20, 2011 at 08:03:59AM +, David Holland wrote:
> In just about every other test suite I've used (which includes some
> very large ones with turing complete/scripted test harness programs
> and other fancy stuff) there are test programs and test driver
> scripts, but all the pieces h
On Wed, Jun 29, 2011 at 03:05:09PM +0100, Julio Merino wrote:
>>> Perhaps if atf were less intrusive...?
>>
>> What do you mean? I think it needs to be quite intrusive
>> (sandboxing, etc.). Unquestionably the old /regress-style is not
>> the way to go. Even if you dislike some parts of the
On Wed, 29 Jun 2011, Jukka Ruohonen wrote:
> On Wed, Jun 29, 2011 at 10:50:22AM +0100, Julio Merino wrote:
> > One of the ideas floating around in my head is to make atf-run (well,
> > kyua) support "foreign" tests. The most basic form of this would be
> > programs that just return 0 on success o
On 6/29/11 2:59 PM, Jukka Ruohonen wrote:
> On Tue, Jun 28, 2011 at 06:50:50AM +, David Holland wrote:
>> Perhaps if atf were less intrusive...?
>
> What do you mean? I think it needs to be quite intrusive (sandboxing, etc.).
> Unquestionably the old /regress-style is not the way to go. Even i
On Tue, Jun 28, 2011 at 06:50:50AM +, David Holland wrote:
> Perhaps if atf were less intrusive...?
What do you mean? I think it needs to be quite intrusive (sandboxing, etc.).
Unquestionably the old /regress-style is not the way to go. Even if you
dislike some parts of the API, already the co
On 6/28/11 7:25 AM, Jukka Ruohonen wrote:
> On Tue, Jun 28, 2011 at 08:12:26AM +0200, Alistair Crooks wrote:
>> 3. they are candidates for modifying to work under atf, I have yet to
>> get the time to do that
>>
>> 4. luke kindly made some gnu autotests for them a while ago
>>
>> [...]
>>
>> and i
On Tue, Jun 28, 2011 at 09:25:32AM +0300, Jukka Ruohonen wrote:
> But I think this entails a wider discussion about how the tests
> shipped with third-party software could be integrated to atf(7). In
> case of netpgp(1) this is easy; a relatively small code base for
> which both in-house tests
On Tue, Jun 28, 2011 at 08:12:26AM +0200, Alistair Crooks wrote:
> 3. they are candidates for modifying to work under atf, I have yet to
> get the time to do that
>
> 4. luke kindly made some gnu autotests for them a while ago
>
> [...]
>
> and if someone was to offer to convert these tests to a
On Tue, Jun 28, 2011 at 07:45:07AM +0300, Jukka Ruohonen wrote:
> On Tue, Jun 28, 2011 at 03:29:39AM +, Alistair G. Crooks wrote:
> > Module Name:src
> > Committed By: agc
> > Date: Tue Jun 28 03:29:38 UTC 2011
> >
> > Modified Files:
> > src/crypto/external/bsd
On Tue, Jun 28, 2011 at 03:29:39AM +, Alistair G. Crooks wrote:
> Module Name: src
> Committed By: agc
> Date: Tue Jun 28 03:29:38 UTC 2011
>
> Modified Files:
> src/crypto/external/bsd/netpgp/dist: tst
>
> Log Message:
> re-do the tests so that it's much easier to see at a gla
On Sun, Aug 15, 2010 at 05:16:47PM +, Christos Zoulas wrote:
> In article <20100815163624.8645d17...@cvs.netbsd.org>,
> Alistair G. Crooks wrote:
> >-=-=-=-=-=-
> >
> >Module Name: src
> >Committed By:agc
> >Date:Sun Aug 15 16:36:24 UTC 2010
> >
> >Modified Files:
> >
In article <20100815163624.8645d17...@cvs.netbsd.org>,
Alistair G. Crooks wrote:
>-=-=-=-=-=-
>
>Module Name: src
>Committed By: agc
>Date: Sun Aug 15 16:36:24 UTC 2010
>
>Modified Files:
> src/crypto/external/bsd/netpgp/dist/src/lib: misc.c packet-parse.c
> packet-show
On Mon, Jul 26, 2010 at 03:56:07AM -0700, Tom Spindler wrote:
> > Modified Files:
> > src/crypto/external/bsd/netpgp/dist/src/lib: keyring.h packet-print.c
> > Added Files:
> > src/crypto/external/bsd/netpgp/dist/src/lib: mj.c mj.h
> >
> > Log Message:
> > add a minimalist JSON implementat
> Modified Files:
> src/crypto/external/bsd/netpgp/dist/src/lib: keyring.h packet-print.c
> Added Files:
> src/crypto/external/bsd/netpgp/dist/src/lib: mj.c mj.h
>
> Log Message:
> add a minimalist JSON implementation, and add a new function to access the
> data, and serialise it using
On Sat, 26 Jun 2010, David Holland wrote:
> I suppose the best available comprehensive solution is to use PRIu***
> garble in the code and then if necessary have autoconf figure out what
> the garble should expand to based on SIZE_MAX.
Yes.
--apb (Alan Barrett)
On Sun, Jun 27, 2010 at 08:10:41PM +0200, Joerg Sonnenberger wrote:
> > Compromising the autoconfiguration not work properly in the name of
> > cross-compilation, though, is misguided. Can't you have it run the
> > test if it's not a cross-compiler and only if it is fall back to the
> > platfor
On Sat, Jun 26, 2010 at 11:21:37PM +, David Holland wrote:
> On Sat, Jun 26, 2010 at 06:25:23AM +0200, Joerg Sonnenberger wrote:
> > > It would be better to make this a check which is size_t dependent,
> > > rather than platform-dependent.
> >
> > The idea is to black list platforms that d
On Sat, Jun 26, 2010 at 06:25:23AM +0200, Joerg Sonnenberger wrote:
> > It would be better to make this a check which is size_t dependent,
> > rather than platform-dependent.
>
> The idea is to black list platforms that don't do %zu and there is no
> way to do that without breaking cross-comp
On Sat, Jun 26, 2010 at 06:18:11AM +0200, Alistair Crooks wrote:
> It would be better to make this a check which is size_t dependent,
> rather than platform-dependent.
The idea is to black list platforms that don't do %zu and there is no
way to do that without breaking cross-compilation. It is sti
On Sat, Jun 26, 2010 at 05:25:31AM +0200, Joerg Sonnenberger wrote:
> On Sat, Jun 26, 2010 at 05:11:39AM +0200, Alistair Crooks wrote:
> > On Sat, Jun 26, 2010 at 01:32:05AM +0200, Joerg Sonnenberger wrote:
> > > On Fri, Jun 25, 2010 at 11:54:32PM +0200, Alistair Crooks wrote:
> > > > Even
On Fri, Jun 25, 2010 at 09:34:12PM -0600, M. Warner Losh wrote:
> You could easily enough have something like the following in autoconf
> to generate that:
>
> #include
> #include
>
> int main(int argc, char **argv)
> {
> size_t foo = ~0;
> printf("#ifndef SIZE_MAX\n#define SIZE_MAX
In message: <20100626032531.ga14...@britannica.bec.de>
Joerg Sonnenberger writes:
: On Sat, Jun 26, 2010 at 05:11:39AM +0200, Alistair Crooks wrote:
: > On Sat, Jun 26, 2010 at 01:32:05AM +0200, Joerg Sonnenberger wrote:
: > > On Fri, Jun 25, 2010 at 11:54:32PM +0200, Alistair Crooks w
On Sat, Jun 26, 2010 at 05:11:39AM +0200, Alistair Crooks wrote:
> On Sat, Jun 26, 2010 at 01:32:05AM +0200, Joerg Sonnenberger wrote:
> > On Fri, Jun 25, 2010 at 11:54:32PM +0200, Alistair Crooks wrote:
> > > Even in C99, the "%lu" method will work unless size_t is bigger than
> > > unsigned l
On Sat, Jun 26, 2010 at 01:32:05AM +0200, Joerg Sonnenberger wrote:
> On Fri, Jun 25, 2010 at 11:54:32PM +0200, Alistair Crooks wrote:
> > Even in C99, the "%lu" method will work unless size_t is bigger than
> > unsigned long *and* the value being printed exceeds ULONG_MAX, which
> > is
On Fri, Jun 25, 2010 at 11:54:32PM +0200, Alistair Crooks wrote:
> Even in C99, the "%lu" method will work unless size_t is bigger than
> unsigned long *and* the value being printed exceeds ULONG_MAX, which
> is unlikely to happen in practice.
Actually, it doesn't. This method br
On Fri, Jun 25, 2010 at 08:40:26PM +, Christos Zoulas wrote:
> In article <20100625183016.ac0be17...@cvs.netbsd.org>,
> Alistair G. Crooks wrote:
> >-=-=-=-=-=-
> >
> >Module Name: src
> >Committed By:agc
> >Date:Fri Jun 25 18:30:16 UTC 2010
> >
> >Modified Files:
> >
In article <20100625183016.ac0be17...@cvs.netbsd.org>,
Alistair G. Crooks wrote:
>-=-=-=-=-=-
>
>Module Name: src
>Committed By: agc
>Date: Fri Jun 25 18:30:16 UTC 2010
>
>Modified Files:
> src/crypto/external/bsd/netpgp/dist/src/lib: misc.c
>
>Log Message:
>Fix build problems on
Joerg Sonnenberger wrote:
> Why do we want to have another ad-hoc HTTP implementation? Wouldn't a
> small *CGI script be good enough?
Argument for a separate implementation: it runs as a standalone daemon
on a different port than the default for HTTP, as a decoupled service
from your normal httpd.
not really, i tried to shoehorn all of this into bozo, and it wasn't
willing to do it, and its cgi subsystem doesn't lend itself to this
kind of thing. i'm fairly intimate with most of bozo's internals,
too.
the server itself is not that large. if there's a common server-side
library that can be
Why do we want to have another ad-hoc HTTP implementation? Wouldn't a
small *CGI script be good enough?
Joerg
On Mon, Mar 01, 2010 at 07:41:57AM +, Alistair G. Crooks wrote:
> Module Name: src
> Committed By: agc
> Date: Mon Mar 1 07:41:57 UTC 2010
>
> Added Files:
> src/cryp
"Alistair G. Crooks" writes:
> Modified Files:
> src/crypto/external/bsd/netpgp/dist: TODO
> src/crypto/external/bsd/netpgp/dist/include: netpgp.h
> src/crypto/external/bsd/netpgp/dist/src/lib: compress.c create.c
> crypto.c crypto.h keyring.c keyring.h misc.c netpgp.c
On Tue, May 26, 2009 at 09:12:39AM +0200, Joerg Sonnenberger wrote:
> On Tue, May 26, 2009 at 05:40:03AM +, Luke Mewburn wrote:
> > Log Message:
> > Improve SHA256_CTX checks; OS/X provides it in
> > even though their is too old.
>
> I think I will hit similiar issues with libarchive at some
In message: <87k543mfzx@snark.cb.piermont.com>
"Perry E. Metzger" writes:
:
: David Holland writes:
: > On Mon, May 11, 2009 at 10:32:30AM -0400, Perry E. Metzger wrote:
: > > The only thing I will directly advocate for (besides scrapping the
: > > current UI) is something like
David Holland writes:
> On Mon, May 11, 2009 at 10:32:30AM -0400, Perry E. Metzger wrote:
> > The only thing I will directly advocate for (besides scrapping the
> > current UI) is something like the ssh-agent functionality. It is painful
> > having to type in your passphrase for every email me
On Mon, May 11, 2009 at 10:32:30AM -0400, Perry E. Metzger wrote:
> The only thing I will directly advocate for (besides scrapping the
> current UI) is something like the ssh-agent functionality. It is painful
> having to type in your passphrase for every email message you read,
> every one you
On Tue, May 26, 2009 at 05:40:03AM +, Luke Mewburn wrote:
> Log Message:
> Improve SHA256_CTX checks; OS/X provides it in
> even though their is too old.
I think I will hit similiar issues with libarchive at some points, so do
you have more details here?
Joerg
On Mon, May 25, 2009 at 10:47:00PM +, Christos Zoulas wrote:
> In article <20090525160949.gr14...@nef.pbox.org>,
> Alistair Crooks wrote:
> >Hi Arnaud, everyone,
> >
> >On Thu, May 21, 2009 at 10:59:04PM -0400, Arnaud Lacombe wrote:
> >> I've been seeing a lot of commit and activity in netpgp
In article <20090525160949.gr14...@nef.pbox.org>,
Alistair Crooks wrote:
>Hi Arnaud, everyone,
>
>On Thu, May 21, 2009 at 10:59:04PM -0400, Arnaud Lacombe wrote:
>> I've been seeing a lot of commit and activity in netpgp. Do you mind
>> sending me a small paragraph [for the next CVS activity repo
Hi Arnaud, everyone,
On Thu, May 21, 2009 at 10:59:04PM -0400, Arnaud Lacombe wrote:
> I've been seeing a lot of commit and activity in netpgp. Do you mind
> sending me a small paragraph [for the next CVS activity report] about
> what you're doing in it and what is already possible and what
> dire
g, this was intended to be a private mail, sorry for the noise everybody :/
All my plan to conquer the world have been spotted, damn ...
- Arnaud
On Thu, May 21, 2009 at 10:59 PM, Arnaud Lacombe wrote:
> Hi Alistair,
>
> I've been seeing a lot of commit and activity in netpgp. Do you mind
Hi Alistair,
I've been seeing a lot of commit and activity in netpgp. Do you mind
sending me a small paragraph [for the next CVS activity report] about
what you're doing in it and what is already possible and what
direction does it take ?
Thanks !
- Arnaud
On Thu, May 21, 2009 at 10:28 PM, Ali
"Alistair G. Crooks" writes:
> + allow a choice of hash algorithms for the signature digest (rather
> than hardcoding SHA1 - it is looking as though collisions are easier
> to manufacture based on recent findings)
> + move default signature RSA hash algorithm to SHA256 (from SHA1). This is
>
On Mon, May 11, 2009 at 10:32:30AM -0400, Perry E. Metzger wrote:
| The only thing I will directly advocate for (besides scrapping the
| current UI) is something like the ssh-agent functionality. It is painful
| having to type in your passphrase for every email message you read,
| every one
Alistair Crooks writes:
> I'll look into providing that somehow (I've been of the opinion that
> we need one binary for key management, and one binary for
> signing/verification and encrypting/decrypting for a while now - it's
> the way that the old nbpg SoC project was going too), and that
> def
On Mon, May 11, 2009 at 12:11:03PM +1000, Daniel Carosone wrote:
> On Mon, May 11, 2009 at 02:55:03AM +0100, Alistair Crooks wrote:
> > On Mon, May 11, 2009 at 11:09:40AM +1000, Daniel Carosone wrote:
> > > On Sat, May 09, 2009 at 03:46:28AM +0100, Alistair Crooks wrote:
> > >
> > > > [...] since
On Mon, May 11, 2009 at 02:55:03AM +0100, Alistair Crooks wrote:
> On Mon, May 11, 2009 at 11:09:40AM +1000, Daniel Carosone wrote:
> > On Sat, May 09, 2009 at 03:46:28AM +0100, Alistair Crooks wrote:
> >
> > > [...] since there's no way of changing a PGP passphrase
> > > short of generating a new
On Mon, May 11, 2009 at 02:55:03AM +0100, Alistair Crooks wrote:
> On Mon, May 11, 2009 at 11:09:40AM +1000, Daniel Carosone wrote:
> > On Sat, May 09, 2009 at 03:46:28AM +0100, Alistair Crooks wrote:
> >
> > > [...] since there's no way of changing a PGP passphrase
> > > short of generating a new
On Mon, May 11, 2009 at 11:09:40AM +1000, Daniel Carosone wrote:
> On Sat, May 09, 2009 at 03:46:28AM +0100, Alistair Crooks wrote:
>
> > [...] since there's no way of changing a PGP passphrase
> > short of generating a new key.
>
> Huh? Sure, you have a need to deal with keyring copies from bef
On Sat, May 09, 2009 at 03:46:28AM +0100, Alistair Crooks wrote:
> [...] since there's no way of changing a PGP passphrase
> short of generating a new key.
Huh? Sure, you have a need to deal with keyring copies from before
the change, maybe with some more rm -P and its limtations, but
otherwise,
Simon Burge writes:
> "Perry E. Metzger" wrote:
>
>> [ ... ] Encrypted swap should
>> be the default -- either using cgd or by simply encrypting the blocks as
>> they go in and out without using the cgd layer.
>
> You've benchmarked the effect of this, especially on older hardware?
No, but other
On Sat, 9 May 2009 03:46:28 +0100
Alistair Crooks wrote:
> On Fri, May 08, 2009 at 01:18:38PM -0400, Perry E. Metzger wrote:
> >
> > "Alistair G. Crooks" writes:
> >
> > > Module Name: src
> > > Committed By: agc
> > > Date: Fri May 8 06:06:39 UTC 2009
> > >
> > > Modifie
Simon Burge wrote:
"Perry E. Metzger" wrote:
[ ... ] Encrypted swap should
be the default -- either using cgd or by simply encrypting the blocks as
they go in and out without using the cgd layer.
You've benchmarked the effect of this, especially on older hardware?
Let's first have it as an
On Sat, May 09, 2009 at 12:44:27PM -0400, Perry E. Metzger wrote:
> By that token, it would be of use for NetBSD to port over the encrypted
> swap features other OSes have (it should be essentially no performance
> hit),
Writing even an encrypted copy of a passphrase to disk is still a
hazard
"Perry E. Metzger" wrote:
> [ ... ] Encrypted swap should
> be the default -- either using cgd or by simply encrypting the blocks as
> they go in and out without using the cgd layer.
You've benchmarked the effect of this, especially on older hardware?
Simon.
Lubomir Sedlacik writes:
> On Sat, May 09, 2009 at 12:44:27PM -0400, Perry E. Metzger wrote:
>> By that token, it would be of use for NetBSD to port over the
>> encrypted swap features other OSes have (it should be essentially no
>> performance hit), [...]
>
> Perry, you can use cgd(4) with rando
On Sat, May 09, 2009 at 12:44:27PM -0400, Perry E. Metzger wrote:
> By that token, it would be of use for NetBSD to port over the
> encrypted swap features other OSes have (it should be essentially no
> performance hit), [...]
Perry, you can use cgd(4) with random key for swap for years on NetBSD.
Alistair Crooks writes:
>> What's the threat model this is protecting against? Presumably, if a
>> user can execute the program, and the program can read his keys, the
>> uesr can already read his own keys, so having a core dump doesn't give
>> the user information he didn't already have.
>
> Heh
On Fri, May 08, 2009 at 01:18:38PM -0400, Perry E. Metzger wrote:
>
> "Alistair G. Crooks" writes:
>
> > Module Name:src
> > Committed By: agc
> > Date: Fri May 8 06:06:39 UTC 2009
> >
> > Modified Files:
> > src/crypto/external/bsd/netpgp/dist: TODO configure co
"Perry E. Metzger" writes:
> Alistair Crooks writes:
>> On Wed, May 06, 2009 at 06:47:37PM +0200, Joerg Sonnenberger wrote:
>>> On Wed, May 06, 2009 at 03:52:15PM +0100, Alistair Crooks wrote:
You're right, if you believe that the failure of a runtime check for
the length of time_t bei
"Alistair G. Crooks" writes:
> Module Name: src
> Committed By: agc
> Date: Fri May 8 06:06:39 UTC 2009
>
> Modified Files:
> src/crypto/external/bsd/netpgp/dist: TODO configure configure.ac
> src/crypto/external/bsd/netpgp/dist/src/bin: netpgp.c
> src/crypto/external
Alistair Crooks writes:
>> Often, when one is writing code like this, one assumes something like
>> the idea that time_t is always, say, four bytes. Then, later, someone
>> like Christos comes along and turns the value into an eight byte
>> quantity and assumptions fail. It is nice to have the as
On Thu, May 07, 2009 at 11:09:57PM -0400, Perry E. Metzger wrote:
>
> Alistair Crooks writes:
> > On Wed, May 06, 2009 at 06:47:37PM +0200, Joerg Sonnenberger wrote:
> >> On Wed, May 06, 2009 at 03:52:15PM +0100, Alistair Crooks wrote:
> >> > You're right, if you believe that the failure of a run
Alistair Crooks writes:
> On Wed, May 06, 2009 at 06:47:37PM +0200, Joerg Sonnenberger wrote:
>> On Wed, May 06, 2009 at 03:52:15PM +0100, Alistair Crooks wrote:
>> > You're right, if you believe that the failure of a runtime check for
>> > the length of time_t being greater than or equal to 4 by
On Wed, May 06, 2009 at 06:47:37PM +0200, Joerg Sonnenberger wrote:
> On Wed, May 06, 2009 at 03:52:15PM +0100, Alistair Crooks wrote:
> > You're right, if you believe that the failure of a runtime check for
> > the length of time_t being greater than or equal to 4 bytes is
> > sufficient to abort
On Wed, May 06, 2009 at 03:52:15PM +0100, Alistair Crooks wrote:
> You're right, if you believe that the failure of a runtime check for
> the length of time_t being greater than or equal to 4 bytes is
> sufficient to abort an application.
...which can and should be a compile-time assertion.
Joerg
On Wed, May 06, 2009 at 12:57:06PM +0200, Klaus Klein wrote:
> On Tue, May 05, 2009 at 11:38:36PM +, David Holland wrote:
> > On Wed, May 06, 2009 at 12:33:00AM +0100, Alistair Crooks wrote:
> > > Imagine someone embedding this library in their (embedded) product.
> > > Having the library dum
On Tue, May 05, 2009 at 11:38:36PM +, David Holland wrote:
> On Wed, May 06, 2009 at 12:33:00AM +0100, Alistair Crooks wrote:
> > Imagine someone embedding this library in their (embedded) product.
> > Having the library dump core for what is an unusual ocurrence, admittedly
> > (such as an
On Tue, May 05, 2009 at 11:38:36PM +, David Holland wrote:
> Having things fail silently or go into a fugue state is not an
> improvement, particularly in security code. So I'd qualify all this by
> saying that end-to-end behavior should always be fail-stop.
Since this is apparently not tha
On Wed, May 06, 2009 at 12:33:00AM +0100, Alistair Crooks wrote:
> Imagine someone embedding this library in their (embedded) product.
> Having the library dump core for what is an unusual ocurrence, admittedly
> (such as an out of memory condition, perhaps) is suboptimal, since the
> product m
On Tue, May 05, 2009 at 11:52:09AM -0400, Perry E. Metzger wrote:
>
> "Alistair G. Crooks" writes:
> > + get rid of some assertions in the code - this is a library - about 100 to
> > go
>
> Why does the fact that it is a library make assertions a bad thing,
> especially in security code?
It do
"Alistair G. Crooks" writes:
> + get rid of some assertions in the code - this is a library - about 100 to go
Why does the fact that it is a library make assertions a bad thing,
especially in security code?
Perry
87 matches
Mail list logo
