On 4/29/14, H??ctor Luis Gimbatti wrote:
> The constant MFSNAMELEN as defined in:
>
> lib/libc/sys/getfsstat.2:#define MFSNAMELEN 16
> lib/libc/sys/statfs.2:#define MFSNAMELEN 16
> sys/sys/mount.h: #define MFSNAMELEN 16
>
> defines the fs type name and, according to comments, it inclu
On 2014/05/01 20:00, Jon Tibble wrote:
> On 01/05/2014 18:10, Ted Unangst wrote:
> >Starting today, we're going to try sending patches out via email
> >so you don't miss them.
> >
> >Several previous errata have also been recently published for OpenBSD
> >5.4 and 5.5. We won't be mailing them out i
On 01/05/2014 18:10, Ted Unangst wrote:
Starting today, we're going to try sending patches out via email
so you don't miss them.
Several previous errata have also been recently published for OpenBSD
5.4 and 5.5. We won't be mailing them out individually since they
aren't new, but you should chec
so, vlan:
-calls ether_ifattach, which, last not least, sets if_type to IFT_ETHER
-right after set if_type to IFT_L2VLAN
-just to set it to if_ether again as soon as it gets configured
(parents can only be IFT_ETHER)
that is... pointless.
fwiw, this was the one and only use of IFT_L2VLAN in the
because it's better than one.
frankly, it's a starting point. if 8 or 42 is better we can tune from there.
or replace it with something that's better to do the same thing - if
that can be come up with. Do you have a better suggestion?
On Thu, May 1, 2014 at 12:52 PM, Marc Espie wrote:
> Sorry,
On Thu, May 01, 2014 at 20:52, Marc Espie wrote:
> Sorry, badly phrased reply. I didn't mean to imply it was a bad idea, but
> you didn't explain at all why 4, and not 3 or 6, or 42 ? If it's good with
> 4, it ought to be better with more, right ? any data point or rationale for
> choosing 4 ?
Th
> Sorry, badly phrased reply. I didn't mean to imply it was a bad idea, but
> you didn't explain at all why 4, and not 3 or 6, or 42 ? If it's good with
> 4, it ought to be better with more, right ? any data point or rationale for
> choosing 4 ?
Why does Ted have to explain his heuristic?
Should
Sorry, badly phrased reply. I didn't mean to imply it was a bad idea, but
you didn't explain at all why 4, and not 3 or 6, or 42 ? If it's good with
4, it ought to be better with more, right ? any data point or rationale for
choosing 4 ?
Okay, the question is: why 4 ? why not 3 ? or 2 ? or 8 ?
Where do you stop ? how did you figure out that 4 was better ?
This looks a bit like "hey, let's make our own crypto code, it ought to
work just fine, right ?"
After sending my previous reply I noticed that you already committed
your diff, so here are my comments again in the form of a proper diff:
* Use NULL instead of casting 0 to pointer types
* Remove unnecessary (char *) cast on buf because buf was already
declared as char *
* Simplify "if ((rc
Starting today, we're going to try sending patches out via email
so you don't miss them.
Several previous errata have also been recently published for OpenBSD
5.4 and 5.5. We won't be mailing them out individually since they
aren't new, but you should check the web site for details.
Refer to http
>From http://www.openbsd.org/errata55.html:
untrusted comment: signature from openbsd 5.5 base secret key
RWRGy8gxk9N9321DQnPP+9IApvSKgX2JT78ZuEZ9HWNUESOfE91CMPQIevj7Yrafs1Zc/KNELplMHCwmFTL8CBjPjuXfEG9y+gU=
OpenBSD 5.5 errata 5, May 1, 2014: An attacker can trigger generation
of an SSL alert whi
Now that the 5.5 release is out, I'd like to remind everyone that
(unlike previous releases) the distribution is signed. Also,
snapshots are signed on a continuous basis.
I would like to thank M:tier for supplying more than half of the
signing infrastructure. The remainder came from the OpenBSD
May 1, 2014.
We are pleased to announce the official release of OpenBSD 5.5.
This is our 35th release on CD-ROM (and 36th via FTP). We remain
proud of OpenBSD's record of more than ten years with only two remote
holes in the default install.
As in our previous releases, 5.5 provides significant
Lots of things get allocated with malloc. Including structures with
function pointers in them. I don't count myself as an exploit expert,
but I do know if I can manage to get to a situation where I have a
writable, predictable location in memory that I know will get called
in short order by someth
On Thu, May 01, 2014 at 15:57, Damien Miller wrote:
> On Thu, 1 May 2014, Ted Unangst wrote:
>
>> What's better than a freelist? Four freelists!
>
> Apart from moar = better, what's the motivation? Do you have a particular
> attack in mind? The only thing I can think of where this change might he
16 matches
Mail list logo
