This diff simplifies the verification of ICMP checksums in
pf_check_proto_cksum() by letting it use the same in4_cksum() call that
is used for TCP and UDP checksums.
As a bonus, since in4_cksum() doesn't need that m_data/m_len dance the
code becomes much shorter as well.
OK?
Index: pf.c
===
Latest snap (2014-01-22) has same bug although I don't recall the
original one rebooting after the crash as this one does. OTOH cranial
memory rusty...
On Wed, 22 Jan 2014 12:09:44 +1100, Rod Whitworth wrote:
>Date 2014-01-20
>Downloaded copies from two mirrors same result.
>Second one from Edmo
On 23/01/2014 12:52 AM, Bob Beck wrote:
I think I'll make sure to advertise the next OpenBSD Foundation
funding campaign by suggesting that you're not actually not real
people, but a helpful-suggestions-posting-bot sponsored by the NSA..
Or maybe it's that they've infiltrated our educational sy
We did print the whole blowfish implementation on the back of a t-shirt,
and I can still read mine. So a key should not be a problem. :-)
. Ken
On 23 January 2014 09:13, Ted Unangst wrote:
> On Wed, Jan 22, 2014 at 11:28, Stuart Henderson wrote:
> > (IIRC somebody suggested printing keys o
On Wed, Jan 22, 2014 at 11:28, Stuart Henderson wrote:
> (IIRC somebody suggested printing keys on the tshirts, not sure if print
> resolution on fabric is really up to that without making the text so
> big as to be horribly ugly, posters may work though.)
It's only 56 letters. 3 rows of 19 should
Em 22-01-2014 11:00, Bob Beck escreveu:
> Our lists are so full of helpful smart people who think chains of
> trust are magical pixie dust coming from root-provider-fairylands
> where the root cert faires live in castles of uncompromising fortitude
> that are never full of government plants and are
On Wed, 22 Jan 2014 10:26:47 +0100, Otto Moerbeek wrote:
> yeah, I first had that and then deleted it.
OK.
- todd
On Wed, Jan 22, 2014 at 15:33, Christian Weisgerber wrote:
> Theo de Raadt wrote:
>
>> There are a few raw edges still, but we would appreciate if this is
>> tried by a few people.. please give us feedback.
>
> Well, it works for me for installs and updates on amd64 and i386.
>
> The limitation
Theo de Raadt wrote:
> There are a few raw edges still, but we would appreciate if this is
> tried by a few people.. please give us feedback.
Well, it works for me for installs and updates on amd64 and i386.
The limitation that the sets are only downloaded and verified if
/home is a separate mo
previously on this list Jiri B contributed:
> What about as TXT record for dns (in combination with DNSSEC) as alternative
> for getting the key? :)
The architecture for the root key handling (offline keys, multiple
people etc.) is good obviously with bobs concerns though.
I don't know much abou
> I think I'll make sure to advertise the next OpenBSD Foundation
> funding campaign by suggesting that you're not actually not real
> people, but a helpful-suggestions-posting-bot sponsored by the NSA..
> Or maybe it's that they've infiltrated our educational systems...
> Please get our your tinf
Our lists are so full of helpful smart people who think chains of
trust are magical pixie dust coming from root-provider-fairylands
where the root cert faires live in castles of uncompromising fortitude
that are never full of government plants and are whose certificates
are magically transported in
Yeah. Ok mister chicken before egg.. We should validate this thing
shipped in a release using dnssec with a root of trust depending on root
certs shipped with the release...Love that idea.. But maybe I'll just
buy a CD.
On 22 Jan 2014 05:13, "Jiri B" wrote:
> On Wed, Jan 22, 2014 at 11:28
On Wed, Jan 22, 2014 at 11:28:50AM +, Stuart Henderson wrote:
> The model is: only the specific keys placed in /etc/signify are trusted.
>
> The plan is to include the public keys used for signing release n+1 in
> release n. So once you trust a particular key, by verifying signatures
> on sets
On 2014/01/22 13:46, Loganaden Velvindron wrote:
> On Fri, Jan 17, 2014 at 3:26 PM, Marc Espie wrote:
> > It's probably time to talk about it.
> >
> > Yes, we are now distributing signed packages. A lot of people have probably
> > noticed because there was a key mismatch on at least one batch of
On Wed, Jan 22, 2014 at 01:46:33PM +0400, Loganaden Velvindron wrote:
> > The signing framework in pkg_add/pkg_create is much older than that, if
> > was written for x509 a few years ago, but signify(1) will probably be more
> > robust and ways simpler. In particular, there's no "chain-of-trust",
Network addresses added to the interface local list thought ifa_add()
are the link-local address and the IPv4/6 ones.
Since if_detach() now calls in_ifdetach(), there should be no address
left on the list apart from the link-layer one at this stage. So the
diff below removes it directly, there's
On Wed, Jan 22, 2014 at 11:29:59AM +0100, Martin Pieuchot wrote:
> Diff below kills the unused RTAX_NETMASK arguments and the global
> variable associated of two requests where a route to host is added
> or deleted.
>
> ok?
OK, setting RTF_HOST and passing a netmask is crazy talk so kill it.
>
Diff below kills the unused RTAX_NETMASK arguments and the global
variable associated of two requests where a route to host is added
or deleted.
ok?
Index: netinet6/in6.c
===
RCS file: /home/ncvs/src/sys/netinet6/in6.c,v
retrieving r
RIP. ok krw@
On 22 January 2014 23:05, Claudio Jeker wrote:
> The RN_DEBUG code is broken since rev 1.1
> I see no reason to keep it any longer and removing the code makes the
> result easier to read.
>
> OK?
> --
> :wq Claudio
>
> Index: net/radix.c
> ==
The RN_DEBUG code is broken since rev 1.1
I see no reason to keep it any longer and removing the code makes the
result easier to read.
OK?
--
:wq Claudio
Index: net/radix.c
===
RCS file: /cvs/src/sys/net/radix.c,v
retrieving revisio
On Fri, Jan 17, 2014 at 3:26 PM, Marc Espie wrote:
> It's probably time to talk about it.
>
> Yes, we are now distributing signed packages. A lot of people have probably
> noticed because there was a key mismatch on at least one batch of signed
> packages.
>
> Obviously, we haven't finished testi
On Tue, Jan 21, 2014 at 11:58:44AM -0700, Todd C. Miller wrote:
> On Tue, 21 Jan 2014 10:44:00 +0100, Otto Moerbeek wrote:
>
> > And here's the man page diff, our ctime and asctime actually do not
> > ever return NULL, while posix allows that.
>
> Isn't it worth documenting that ctime and asctim
23 matches
Mail list logo
