On 11.05.2014 13:10, Creamy wrote:
On Sun, May 11, 2014 at 06:52:51AM -0400, Kenneth Westerback wrote:
On 11 May 2014 06:38, Creamy wrote:
> On Sun, May 11, 2014 at 06:03:24AM -0400, Kenneth Westerback
wrote:
>> On 11 May 2014 05:26, "Creamy" wrote:
>> >
>> > Hello again!
>> >
>> > OK, thi
From: Brent Cook
Remove support for parsing the unused -rand option and the unused random
buffer variables.
---
src/apps/cms.c | 9 -
src/apps/dgst.c | 8 ++--
src/apps/dhparam.c | 10 +-
src/apps/dsaparam.c | 7 +--
src/apps/ecparam.c | 9 +
src/ap
From: Brent Cook
Avoid having to use -I trickery to find public header files included as
though they are private.
---
src/crypto/bn/bn_const.c | 2 +-
src/crypto/chacha/chacha.c | 2 +-
src/crypto/o_init.c | 2 +-
src/crypto/pqueue/pqueue.c | 2 +-
src/crypto/ts/ts_lib.c |
From: Brent Cook
Neither of these is used anywhere within their object files.
---
src/crypto/ec/ec_lib.c | 3 ---
src/crypto/engine/eng_dyn.c | 3 ---
2 files changed, 6 deletions(-)
diff --git a/src/crypto/ec/ec_lib.c b/src/crypto/ec/ec_lib.c
index b37efac..37dfd17 100644
--- a/src/crypto
From: Brent Cook
write() warns if its return value is unchecked. Replace with a BIO_write
like all of the surrounding code uses anyway.
---
src/apps/s_server.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/apps/s_server.c b/src/apps/s_server.c
index 4e1..729c94d 100
Hi all,
This is a set of generic fixes to libssl/crypto that I found building with
GCC 4.8 and Clang from LLVM 5.1.
The first patch seems to be an actual bug, while the others are a little more
pedantic (removing unused variables, fixing signed/unsigned char * aliases).
- Brent
From: Brent Cook
ASN1_STRING_data returns an unsigned char *, but strlcat's second
parameter is a const char *
---
src/crypto/ts/ts_rsp_verify.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/crypto/ts/ts_rsp_verify.c b/src/crypto/ts/ts_rsp_verify.c
index 2a4c0c5..49754b
From: Brent Cook
If EVP_DecryptInit_ex() returns NULL, j is incremented by a random amount.
clang warning:
pem/pem_lib.c:472:6: error: variable 'i' is used uninitialized whenever 'if'
condition is false
[-Werror,-Wsometimes-uninitialized]
if (o)
^
pem/pem_lib.c:479:7:
> Shouldn't that be:
>
> +.Op Ic auth | auth-optional | auth Aq Ar authtable Aq | Ic auth-optional Ar
> authtable
>
> ??? Looks like it fixed itself incorrectly :-)))
:-P
But you're right, the fix was wrong, missed that one. But it doesn't
work your way either. If I understand mdoc(7) correct
On 11 May 2014 07:00, Creamy wrote:
> On Sun, May 11, 2014 at 06:31:23AM -0400, Kenneth Westerback wrote:
>> On 11 May 2014 06:03, Kenneth Westerback wrote:
>> >
>> > On 11 May 2014 05:26, "Creamy" wrote:
>> >>
>> >> Hello again!
>> >>
>> >> OK, this time it's a bug, (or is it a feature?), in dh
On Sun, May 11, 2014 at 06:52:51AM -0400, Kenneth Westerback wrote:
> On 11 May 2014 06:38, Creamy wrote:
> > On Sun, May 11, 2014 at 06:03:24AM -0400, Kenneth Westerback wrote:
> >> On 11 May 2014 05:26, "Creamy" wrote:
> >> >
> >> > Hello again!
> >> >
> >> > OK, this time it's a bug, (or is it
On Sun, May 11, 2014 at 06:31:23AM -0400, Kenneth Westerback wrote:
> On 11 May 2014 06:03, Kenneth Westerback wrote:
> >
> > On 11 May 2014 05:26, "Creamy" wrote:
> >>
> >> Hello again!
> >>
> >> OK, this time it's a bug, (or is it a feature?), in dhclient.
> >>
> >> Imagine that you have two se
On 11 May 2014 06:38, Creamy wrote:
> On Sun, May 11, 2014 at 06:03:24AM -0400, Kenneth Westerback wrote:
>> On 11 May 2014 05:26, "Creamy" wrote:
>> >
>> > Hello again!
>> >
>> > OK, this time it's a bug, (or is it a feature?), in dhclient.
>> >
>> > Imagine that you have two separate wireless n
On Sun, May 11, 2014 at 06:03:24AM -0400, Kenneth Westerback wrote:
> On 11 May 2014 05:26, "Creamy" wrote:
> >
> > Hello again!
> >
> > OK, this time it's a bug, (or is it a feature?), in dhclient.
> >
> > Imagine that you have two separate wireless networks, which operate
> > independently using
On 11 May 2014 06:03, Kenneth Westerback wrote:
>
> On 11 May 2014 05:26, "Creamy" wrote:
>>
>> Hello again!
>>
>> OK, this time it's a bug, (or is it a feature?), in dhclient.
>>
>> Imagine that you have two separate wireless networks, which operate
>> independently using the same private addres
On 11 May 2014 05:26, "Creamy" wrote:
>
> Hello again!
>
> OK, this time it's a bug, (or is it a feature?), in dhclient.
>
> Imagine that you have two separate wireless networks, which operate
> independently using the same private address spaces and offer leases
> based on the same algorithm comp
Hello again!
OK, this time it's a bug, (or is it a feature?), in dhclient.
Imagine that you have two separate wireless networks, which operate
independently using the same private address spaces and offer leases
based on the same algorithm computed from the MAC address of the
client.
For example
On Sat, May 10, 2014 at 10:39:22PM +0200, Frank Brodbeck wrote:
> On Sat, May 10, 2014 at 07:03:14PM +0100, Creamy wrote:
> > So the manual page is wrong, or at least misleading, because
> > the syntax of the examples differs between from, sender, and
> > for, so it's not clear whether the angle br
18 matches
Mail list logo
