On Fri, Aug 12, 2016 at 10:39:41AM -0400, Ted Unangst wrote:
> David Gwynne wrote:
> > i recently proposed replacing a hash with an rb tree somewhere in
> > the network stack, but it was pointed out that rb trees are big.
> >
> > in hindsight i think the other person was talking about the size
> >
On Thursday, 25 August 2016, Ted Unangst wrote:
> Andreas Bartelt wrote:
> > On 08/25/16 15:58, Brent Cook wrote:
> > > No objection here. Anyone else?
> > >
> >
> > in general, I personally would only add further cryptographic primitives
> > to a TLS configuration in case they provide sufficient
Todd C. Miller wrote:
> > if (blah) {
> > size_t len;
> > ...
> > } else {
> > size_t len;
> > ...
> > }
> >
> > looks noisy to me, so I would lean towards your latter idea.
>
> Yeah, I just liked len being scoped that way. However, I see other
> places we really want to use a si
On Thu, 25 Aug 2016 13:56:24 -0700, Philip Guenther wrote:
> This:
>
> if (blah) {
> size_t len;
> ...
> } else {
> size_t len;
> ...
> }
>
> looks noisy to me, so I would lean towards your latter idea.
Yeah, I just liked len being scoped that way. However, I see other
places w
On Thu, Aug 25, 2016 at 11:15 AM, Todd C. Miller
wrote:
> This is what strnlen(3) is for, let's use it...
>
> Alternately, we could unify things like:
>
> len = prec >= 0 ? strnlen(cp, prec) : strlen(cp);
> if (len > INT_MAX)
> goto overflow;
> size = (int)l
This is what strnlen(3) is for, let's use it...
Alternately, we could unify things like:
len = prec >= 0 ? strnlen(cp, prec) : strlen(cp);
if (len > INT_MAX)
goto overflow;
size = (int)len;
but that means declaring "size_t len" at the top of the for(;;) lo
On 25.08.2016 17:50, Ingo Schwarze wrote:
> I strongly feel that fgetln(3) ought to behave the same: either
> succeed or fail. It should not return a string but set errno and
> __SERR at the same time. So i'd very much like to commit my fgetln.c
> patch. I have an OK from millert@, which is suff
Andreas Bartelt wrote:
> On 08/25/16 15:58, Brent Cook wrote:
> > No objection here. Anyone else?
> >
>
> in general, I personally would only add further cryptographic primitives
> to a TLS configuration in case they provide sufficiently distinctive
> advantages over the already available primit
Brent Cook wrote:
> No objection here. Anyone else?
No. Camellia doesn't get much attention, but if somebody cares to add new
modes for it, no reason to reject it.
Hi Andrej,
Andrey Chernov wrote on Wed, Aug 24, 2016 at 10:19:35PM +0300:
> On 24.08.2016 22:03, Ingo Schwarze wrote:
>> Andrey Chernov wrote:
>>> Could you show some code? In my testing fgetwln() fails on next read if
>>> previously there was partial line with tail EILSEQ. Stdio not advance
>>>
On 08/25/16 15:58, Brent Cook wrote:
No objection here. Anyone else?
in general, I personally would only add further cryptographic primitives
to a TLS configuration in case they provide sufficiently distinctive
advantages over the already available primitives. I don't see this for
Camellia
On 08/25/16 15:39, Gilles Chehade wrote:
> On Mon, Aug 22, 2016 at 11:10:28PM +0300, Pavel Korovin wrote:
>> Dear all,
>>
>> I have local patch which implements IP/hostname logging for all SMTP
>> operations.
>> It simplifies log processing for me since I don't have to keep reference
>> between se
No objection here. Anyone else?
> On Aug 25, 2016, at 8:54 AM, Guenther Niess wrote:
>
> Hi,
>
> is there a reason why the Camellia cipher suits with SHA2 HMAC is not
> supported?
>
> I added them and tested the result with an Nginx server and the s_client
> command.
>
> I would like to have
Hi,
is there a reason why the Camellia cipher suits with SHA2 HMAC is not
supported?
I added them and tested the result with an Nginx server and the s_client
command.
I would like to have a look to support the Camellia GCM based cipher
suites, but if there is a reason why libressl shouldn't supp
On Mon, Aug 22, 2016 at 11:10:28PM +0300, Pavel Korovin wrote:
> Dear all,
>
> I have local patch which implements IP/hostname logging for all SMTP
> operations.
> It simplifies log processing for me since I don't have to keep reference
> between session ids and IPs/hostnames and check it every t
On 24/08/16(Wed) 21:49, Alexander Bluhm wrote:
> On Wed, Aug 24, 2016 at 05:52:39PM +0200, Martin Pieuchot wrote:
> > Diff below simplifies ip6_getpmtu() to use a 'struct rtentry *' instead
> > of two 'struct route_in6'.
> >
> > ok?
>
> I have tested it with regress/sys/netinet/pmtu .
>
> OK blu
Stuart Henderson writes:
> I don't see any code to support setting pinfoflags from a string,
> it looks like it must be numeric.
>
> OK?
yup
> (If someone wants to add string support sometime that would be
> nice, but let's fix the example in the first case).
Someone(tm) is working on it.
> I
> Date: Wed, 24 Aug 2016 15:43:13 +0300
> From: Artturi Alm
>
> Hi,
>
> been running w/this on wandboard for some days building ports.
> pm_cstate should go too, but it's another small diff.
Thanks. I think I came to the same conclusion when removed the first
bit of cruft from cpuswitch7.S. I
I don't see any code to support setting pinfoflags from a string,
it looks like it must be numeric.
OK?
(If someone wants to add string support sometime that would be
nice, but let's fix the example in the first case).
Index: rtadvd.conf.5
On Thu, Aug 25, 2016 at 03:51:52AM -0400, Rob Pierce wrote:
> ntpd was pledged in 5.9.
Right. In fact, unless I'm missing something, the only pledge-related
commit to ntpd was due to the removal of chroot from the supported
syscalls, so I think "Improved pledge(2) support" is still overstating
the
ntpd was pledged in 5.9.
Rob
Index: 60.html
===
RCS file: /cvs/www/60.html,v
retrieving revision 1.70
diff -u -p -r1.70 60.html
--- 60.html 24 Aug 2016 20:47:30 - 1.70
+++ 60.html 25 Aug 2016 07:48:55 -
@@ -598,7
21 matches
Mail list logo
