Re: 5.5beta wierds
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 asctime are allowed to return NULL, even though they do not on OpenBSD? - todd yeah, I first had that and then deleted it. ok? -Otto Index: ctime.3 === RCS file: /cvs/src/lib/libc/time/ctime.3,v retrieving revision 1.42 diff -u -p -r1.42 ctime.3 --- ctime.3 21 Jan 2014 11:51:02 - 1.42 +++ ctime.3 22 Jan 2014 09:26:33 - @@ -259,6 +259,10 @@ from UTC, with positive values indicatin of the Prime Meridian. .Sh RETURN VALUES The functions +.Fn ctime , +.Fn ctime_r , +.Fn asctime , +.Fn asctime_r , .Fn localtime , .Fn localtime_r , .Fn gmtime
Re: signed packages
On Fri, Jan 17, 2014 at 3:26 PM, Marc Espie es...@nerim.net 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 testing yet. Don't read too much into that. Signed packages just mean you can use an insecure medium, such as ftp, to download packages: if the key matches, it means the package hasn't been tampered with since it was signed. The cryptographic framework used to sign packages is called signify(1), mostly written by Ted Unangst, with a lot of feedback from (mostly) Theo and I. 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, so you keep complete control on the sources YOU trust. Can you please elborate more on the trusting part ? Both DNSSEC and RPKI have a root anchor that we're all supposed to trust, and your model is different. Signatures should be transparent in use: the package is opened, the packing-list signature is checked, and then files are checksummed while extracted against the packing-list embedded checksums (there are provisions to ensure any dangerous meta-data is also encoded in the packing-list as @mode/@user/@group annotations. So, barring problems, you shouldn't even notice signatures. -- This message is strictly personal and the opinions expressed do not represent those of my employers, either past or present.
kill RN_DEBUG code
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 revision 1.38
diff -u -p -r1.38 radix.c
--- net/radix.c 21 Jan 2014 23:42:44 - 1.38
+++ net/radix.c 22 Jan 2014 09:58:42 -
@@ -303,13 +303,6 @@ on1:
return NULL;
}
-#ifdef RN_DEBUG
-intrn_nodenum;
-struct radix_node *rn_clist;
-intrn_saveinfo;
-intrn_debug = 1;
-#endif
-
struct radix_node *
rn_newpair(void *v, int b, struct radix_node nodes[2])
{
@@ -322,13 +315,6 @@ rn_newpair(void *v, int b, struct radix_
tt-rn_key = v;
tt-rn_p = t;
tt-rn_flags = t-rn_flags = RNF_ACTIVE;
-#ifdef RN_DEBUG
- tt-rn_info = rn_nodenum++;
- t-rn_info = rn_nodenum++;
- tt-rn_twin = t;
- tt-rn_ybro = rn_clist;
- rn_clist = tt;
-#endif
return t;
}
@@ -376,10 +362,6 @@ on1:
else
x = x-rn_l;
} while (b (unsigned int) x-rn_b); /* x-rn_b b x-rn_b = 0 */
-#ifdef RN_DEBUG
- if (rn_debug)
- log(LOG_DEBUG, rn_insert: Going In:\n), traverse(p);
-#endif
t = rn_newpair(v_arg, b, nodes);
tt = t-rn_l;
if ((cp[p-rn_off] p-rn_bmask) == 0)
@@ -394,10 +376,6 @@ on1:
t-rn_r = tt;
t-rn_l = x;
}
-#ifdef RN_DEBUG
- if (rn_debug)
- log(LOG_DEBUG, rn_insert: Coming Out:\n), traverse(p);
-#endif
}
return (tt);
}
@@ -640,14 +618,6 @@ rn_addroute(void *v_arg, void *n_arg, st
if (tt-rn_dupedkey)
tt-rn_dupedkey-rn_p = tt;
}
-#ifdef RN_DEBUG
- t=tt+1;
- tt-rn_info = rn_nodenum++;
- t-rn_info = rn_nodenum++;
- tt-rn_twin = t;
- tt-rn_ybro = rn_clist;
- rn_clist = tt;
-#endif
tt-rn_key = (caddr_t) v;
tt-rn_b = -1;
tt-rn_flags = RNF_ACTIVE;
@@ -851,12 +821,6 @@ on1:
*/
if (tt-rn_flags RNF_ROOT)
return (0);
-#ifdef RN_DEBUG
- /* Get us out of the creation list */
- for (t = rn_clist; t t-rn_ybro != tt; t = t-rn_ybro)
- ;
- if (t) t-rn_ybro = tt-rn_ybro;
-#endif
t = tt-rn_p;
dupedkey = saved_tt-rn_dupedkey;
if (dupedkey) {
@@ -879,15 +843,8 @@ on1:
}
t = tt + 1;
if (t-rn_flags RNF_ACTIVE) {
-#ifndef RN_DEBUG
- *++x = *t;
- p = t-rn_p;
-#else
- b = t-rn_info;
*++x = *t;
- t-rn_info = b;
p = t-rn_p;
-#endif
if (p-rn_l == t)
p-rn_l = x;
else
@@ -944,13 +901,7 @@ on1:
*/
x = tt + 1;
if (t != x) {
-#ifndef RN_DEBUG
- *t = *x;
-#else
- b = t-rn_info;
*t = *x;
- t-rn_info = b;
-#endif
t-rn_l-rn_p = t;
t-rn_r-rn_p = t;
p = x-rn_p;
Index: net/radix.h
===
RCS file: /cvs/src/sys/net/radix.h,v
retrieving revision 1.23
diff -u -p -r1.23 radix.h
--- net/radix.h 19 Jan 2014 09:52:25 - 1.23
+++ net/radix.h 22 Jan 2014 09:59:32 -
@@ -60,11 +60,6 @@ struct radix_node {
struct radix_node *rn_R;/* progeny */
} rn_node;
} rn_u;
-#ifdef RN_DEBUG
- int rn_info;
- struct radix_node *rn_twin;
- struct radix_node *rn_ybro;
-#endif
};
#define rn_dupedkey rn_u.rn_leaf.rn_Dupedkey
Index: net/radix_mpath.c
===
RCS file: /cvs/src/sys/net/radix_mpath.c,v
retrieving revision 1.21
diff -u -p -r1.21 radix_mpath.c
--- net/radix_mpath.c 20 Oct 2013 16:17:36 - 1.21
+++ net/radix_mpath.c 22 Jan 2014 09:58:54 -
@@ -60,9 +60,6 @@ u_int32_t rn_mpath_hash(struct route *,
* give some jitter to hash, to avoid synchronization between routers
*/
static u_int32_t hashjitter;
-#ifdef RN_DEBUG
-extern struct radix_node *rn_clist;
-#endif
int
rn_mpath_capable(struct radix_node_head *rnh)
@@ -208,16 +205,6 @@ rn_mpath_reprio(struct radix_node *rn, i
if (rn-rn_dupedkey)
rn-rn_dupedkey-rn_p = rn;
}
-
-#ifdef RN_DEBUG
- /* readd at head of creation list */
- for (t = rn_clist; t t-rn_ybro != rn; t = t-rn_ybro)
- ;
- if (t)
- t-rn_ybro = rn-rn_ybro;
- rn-rn_ybro = rn_clist;
- rn_clist = rn;
-#endif
if (rn-rn_mklist rn-rn_flags
RTF_HOST and netmask
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 revision 1.130
diff -u -p -c -4 -r1.130 in6.c
*** netinet6/in6.c 21 Jan 2014 10:18:26 - 1.130
--- netinet6/in6.c 22 Jan 2014 10:21:00 -
*** const struct sockaddr_in6 sa6_any = {
*** 135,151
void
in6_ifloop_request(int cmd, struct ifaddr *ifa)
{
struct rt_addrinfo info;
- struct sockaddr_in6 all1_sa;
struct rtentry *nrt = NULL;
int e;
- bzero(all1_sa, sizeof(all1_sa));
- all1_sa.sin6_family = AF_INET6;
- all1_sa.sin6_len = sizeof(struct sockaddr_in6);
- all1_sa.sin6_addr = in6mask128;
-
/*
* We specify the address itself as the gateway, and set the
* RTF_LLINFO flag, so that the corresponding host route would have
* the flag, and thus applications that assume traditional behavior
--- 135,145
*** in6_ifloop_request(int cmd, struct ifadd
*** 158,166
info.rti_flags = RTF_UP | RTF_HOST | RTF_LLINFO;
info.rti_info[RTAX_DST] = ifa-ifa_addr;
if (cmd != RTM_DELETE)
info.rti_info[RTAX_GATEWAY] = ifa-ifa_addr;
- info.rti_info[RTAX_NETMASK] = sin6tosa(all1_sa);
e = rtrequest1(cmd, info, RTP_CONNECTED, nrt,
ifa-ifa_ifp-if_rdomain);
if (e != 0) {
char addr[INET6_ADDRSTRLEN];
--- 152,159
Index: netinet6/nd6.c
===
RCS file: /home/ncvs/src/sys/netinet6/nd6.c,v
retrieving revision 1.109
diff -u -p -c -4 -r1.109 nd6.c
*** netinet6/nd6.c 13 Jan 2014 23:03:52 - 1.109
--- netinet6/nd6.c 22 Jan 2014 10:21:00 -
*** struct llinfo_nd6 llinfo_nd6 = {llinfo_
*** 91,99
struct nd_drhead nd_defrouter;
struct nd_prhead nd_prefix = { 0 };
int nd6_recalc_reachtm_interval = ND6_RECALC_REACHTM_INTERVAL;
- static struct sockaddr_in6 all1_sa;
void nd6_setmtu0(struct ifnet *, struct nd_ifinfo *);
void nd6_slowtimo(void *);
struct llinfo_nd6 *nd6_free(struct rtentry *, int);
--- 91,98
*** int fill_prlist(void *, size_t *, size_t
*** 119,138
void
nd6_init(void)
{
static int nd6_init_done = 0;
- int i;
if (nd6_init_done) {
log(LOG_NOTICE, nd6_init called more than once(ignored)\n);
return;
}
- all1_sa.sin6_family = AF_INET6;
- all1_sa.sin6_len = sizeof(struct sockaddr_in6);
- for (i = 0; i sizeof(all1_sa.sin6_addr); i++)
- all1_sa.sin6_addr.s6_addr[i] = 0xff;
-
/* initialization of the default router list */
TAILQ_INIT(nd_defrouter);
nd6_init_done = 1;
--- 118,131
*** nd6_lookup(struct in6_addr *addr6, int c
*** 688,696
info.rti_flags = (ifa-ifa_flags | RTF_HOST |
RTF_LLINFO) ~RTF_CLONING;
info.rti_info[RTAX_DST] = sin6tosa(sin6);
info.rti_info[RTAX_GATEWAY] = ifa-ifa_addr;
- info.rti_info[RTAX_NETMASK] = sin6tosa(all1_sa);
if ((e = rtrequest1(RTM_ADD, info, RTP_CONNECTED,
rt, rtableid)) != 0) {
#if 0
char ip[INET6_ADDRSTRLEN];
--- 681,688
Re: RTF_HOST and netmask
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.
Index: netinet6/in6.c
===
RCS file: /home/ncvs/src/sys/netinet6/in6.c,v
retrieving revision 1.130
diff -u -p -c -4 -r1.130 in6.c
*** netinet6/in6.c21 Jan 2014 10:18:26 - 1.130
--- netinet6/in6.c22 Jan 2014 10:21:00 -
*** const struct sockaddr_in6 sa6_any = {
*** 135,151
void
in6_ifloop_request(int cmd, struct ifaddr *ifa)
{
struct rt_addrinfo info;
- struct sockaddr_in6 all1_sa;
struct rtentry *nrt = NULL;
int e;
- bzero(all1_sa, sizeof(all1_sa));
- all1_sa.sin6_family = AF_INET6;
- all1_sa.sin6_len = sizeof(struct sockaddr_in6);
- all1_sa.sin6_addr = in6mask128;
-
/*
* We specify the address itself as the gateway, and set the
* RTF_LLINFO flag, so that the corresponding host route would have
* the flag, and thus applications that assume traditional behavior
--- 135,145
*** in6_ifloop_request(int cmd, struct ifadd
*** 158,166
info.rti_flags = RTF_UP | RTF_HOST | RTF_LLINFO;
info.rti_info[RTAX_DST] = ifa-ifa_addr;
if (cmd != RTM_DELETE)
info.rti_info[RTAX_GATEWAY] = ifa-ifa_addr;
- info.rti_info[RTAX_NETMASK] = sin6tosa(all1_sa);
e = rtrequest1(cmd, info, RTP_CONNECTED, nrt,
ifa-ifa_ifp-if_rdomain);
if (e != 0) {
char addr[INET6_ADDRSTRLEN];
--- 152,159
Index: netinet6/nd6.c
===
RCS file: /home/ncvs/src/sys/netinet6/nd6.c,v
retrieving revision 1.109
diff -u -p -c -4 -r1.109 nd6.c
*** netinet6/nd6.c13 Jan 2014 23:03:52 - 1.109
--- netinet6/nd6.c22 Jan 2014 10:21:00 -
*** struct llinfo_nd6 llinfo_nd6 = {llinfo_
*** 91,99
struct nd_drhead nd_defrouter;
struct nd_prhead nd_prefix = { 0 };
int nd6_recalc_reachtm_interval = ND6_RECALC_REACHTM_INTERVAL;
- static struct sockaddr_in6 all1_sa;
void nd6_setmtu0(struct ifnet *, struct nd_ifinfo *);
void nd6_slowtimo(void *);
struct llinfo_nd6 *nd6_free(struct rtentry *, int);
--- 91,98
*** int fill_prlist(void *, size_t *, size_t
*** 119,138
void
nd6_init(void)
{
static int nd6_init_done = 0;
- int i;
if (nd6_init_done) {
log(LOG_NOTICE, nd6_init called more than once(ignored)\n);
return;
}
- all1_sa.sin6_family = AF_INET6;
- all1_sa.sin6_len = sizeof(struct sockaddr_in6);
- for (i = 0; i sizeof(all1_sa.sin6_addr); i++)
- all1_sa.sin6_addr.s6_addr[i] = 0xff;
-
/* initialization of the default router list */
TAILQ_INIT(nd_defrouter);
nd6_init_done = 1;
--- 118,131
*** nd6_lookup(struct in6_addr *addr6, int c
*** 688,696
info.rti_flags = (ifa-ifa_flags | RTF_HOST |
RTF_LLINFO) ~RTF_CLONING;
info.rti_info[RTAX_DST] = sin6tosa(sin6);
info.rti_info[RTAX_GATEWAY] = ifa-ifa_addr;
- info.rti_info[RTAX_NETMASK] = sin6tosa(all1_sa);
if ((e = rtrequest1(RTM_ADD, info, RTP_CONNECTED,
rt, rtableid)) != 0) {
#if 0
char ip[INET6_ADDRSTRLEN];
--- 681,688
--
:wq Claudio
if_detach() addresses cleanup
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 no need for a loop anymore.
I left a check for safety afterward...
ok?
Index: net/if.c
===
RCS file: /home/ncvs/src/sys/net/if.c,v
retrieving revision 1.279
diff -u -p -r1.279 if.c
--- net/if.c28 Nov 2013 10:16:44 - 1.279
+++ net/if.c7 Jan 2014 11:57:09 -
@@ -359,12 +359,10 @@ if_free_sadl(struct ifnet *ifp)
s = splnet();
rtinit(ifa, RTM_DELETE, 0);
-#if 0
ifa_del(ifp, ifa);
+ ifafree(ifp-if_lladdr);
ifp-if_lladdr = NULL;
-#endif
ifp-if_sadl = NULL;
-
splx(s);
}
@@ -587,27 +585,22 @@ do { \
if (ISSET(ifp-if_xflags, IFXF_TXREADY))
TAILQ_REMOVE(iftxlist, ifp, if_txlist);
- /*
-* Deallocate private resources.
-*/
- while ((ifa = TAILQ_FIRST(ifp-if_addrlist)) != NULL) {
- ifa_del(ifp, ifa);
- /* XXX if_free_sadl needs this */
- if (ifa == ifp-if_lladdr)
- continue;
-
- ifa-ifa_ifp = NULL;
- ifafree(ifa);
- }
-
while ((ifg = TAILQ_FIRST(ifp-if_groups)) != NULL)
if_delgroup(ifp, ifg-ifgl_group-ifg_group);
if_free_sadl(ifp);
- ifp-if_lladdr-ifa_ifp = NULL;
- ifafree(ifp-if_lladdr);
- ifp-if_lladdr = NULL;
+ /* We should not have any address left at this point. */
+ if (!TAILQ_EMPTY(ifp-if_addrlist)) {
+#ifdef DIAGNOSTIC
+ printf(%s: address list non empty\n, ifp-if_xname);
+#endif
+ while ((ifa = TAILQ_FIRST(ifp-if_addrlist)) != NULL) {
+ ifa_del(ifp, ifa);
+ ifa-ifa_ifp = NULL;
+ ifafree(ifa);
+ }
+ }
free(ifp-if_addrhooks, M_TEMP);
free(ifp-if_linkstatehooks, M_TEMP);
Re: signed packages
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, so you keep complete control on the sources YOU trust. Can you please elborate more on the trusting part ? Both DNSSEC and RPKI have a root anchor that we're all supposed to trust, and your model is different. There's no chain of trust. pkg_add trusts pub keys under /etc/signify that end in *pkg.pub (respectively *fw.pub for firmwares). Put shit there - get shit out. the only way to get keys in there is: - base install, - explicitly putting keys there as root. There's nothing more automated. Keys are not certified nor anything.
Re: signed packages
On 2014/01/22 13:46, Loganaden Velvindron wrote: On Fri, Jan 17, 2014 at 3:26 PM, Marc Espie es...@nerim.net 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 testing yet. Don't read too much into that. Signed packages just mean you can use an insecure medium, such as ftp, to download packages: if the key matches, it means the package hasn't been tampered with since it was signed. The cryptographic framework used to sign packages is called signify(1), mostly written by Ted Unangst, with a lot of feedback from (mostly) Theo and I. 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, so you keep complete control on the sources YOU trust. Can you please elborate more on the trusting part ? Both DNSSEC and RPKI have a root anchor that we're all supposed to trust, and your model is different. 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 which you download+install, you can have a chain of continuity for future keys. You still need to get your initial key from somewhere that you trust. If you are worried about sources of this, you can at least check and compare the 55*.pub files from a few sources e.g. those in downloaded sets against those in anoncvs/cvsweb (cvs -d $CVSROOT get -p src/etc/signify/55base.pub to display on stdout). Of course when the next release is done they'll be on CD. (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.) Given sufficient space to download tgz before unpacking, the install ramdisk kernel now checks signatures (yes: crypto fits on the ramdisk - signify/ed25519 is small, and yes: please test and report on any problems!). If you're fetching a new installer (ramdisk kernel, install55.iso, floppy*.fs, etc) you can verify the signature of that file before using it. Also it should go without saying, if you use the untar sets on a running system method, checking those sets is your responsibility, see signify(1)'s EXAMPLES section for information about how to do this.
Re: signed packages
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 which you download+install, you can have a chain of continuity for future keys. You still need to get your initial key from somewhere that you trust. If you are worried about sources of this, you can at least check and compare the 55*.pub files from a few sources e.g. those in downloaded sets against those in anoncvs/cvsweb (cvs -d $CVSROOT get -p src/etc/signify/55base.pub to display on stdout). Of course when the next release is done they'll be on CD. (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.) Given sufficient space to download tgz before unpacking, the install ramdisk kernel now checks signatures (yes: crypto fits on the ramdisk - signify/ed25519 is small, and yes: please test and report on any problems!). If you're fetching a new installer (ramdisk kernel, install55.iso, floppy*.fs, etc) you can verify the signature of that file before using it. Also it should go without saying, if you use the untar sets on a running system method, checking those sets is your responsibility, see signify(1)'s EXAMPLES section for information about how to do this. What about as TXT record for dns (in combination with DNSSEC) as alternative for getting the key? :) jirib
Re: signed packages
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 ji...@devio.us wrote: 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 which you download+install, you can have a chain of continuity for future keys. You still need to get your initial key from somewhere that you trust. If you are worried about sources of this, you can at least check and compare the 55*.pub files from a few sources e.g. those in downloaded sets against those in anoncvs/cvsweb (cvs -d $CVSROOT get -p src/etc/signify/55base.pub to display on stdout). Of course when the next release is done they'll be on CD. (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.) Given sufficient space to download tgz before unpacking, the install ramdisk kernel now checks signatures (yes: crypto fits on the ramdisk - signify/ed25519 is small, and yes: please test and report on any problems!). If you're fetching a new installer (ramdisk kernel, install55.iso, floppy*.fs, etc) you can verify the signature of that file before using it. Also it should go without saying, if you use the untar sets on a running system method, checking those sets is your responsibility, see signify(1)'s EXAMPLES section for information about how to do this. What about as TXT record for dns (in combination with DNSSEC) as alternative for getting the key? :) jirib
Re: signed packages
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 into operating systems and placed in that special place in our hearts where no file could ever be modified... They also suggest we should move the machines that generate the releases into of those same castles where power is cheaper to save money... 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 tinfoil hats kids. On Wed, Jan 22, 2014 at 5:39 AM, Bob Beck b...@obtuse.com wrote: 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 ji...@devio.us wrote: 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 which you download+install, you can have a chain of continuity for future keys. You still need to get your initial key from somewhere that you trust. If you are worried about sources of this, you can at least check and compare the 55*.pub files from a few sources e.g. those in downloaded sets against those in anoncvs/cvsweb (cvs -d $CVSROOT get -p src/etc/signify/55base.pub to display on stdout). Of course when the next release is done they'll be on CD. (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.) Given sufficient space to download tgz before unpacking, the install ramdisk kernel now checks signatures (yes: crypto fits on the ramdisk - signify/ed25519 is small, and yes: please test and report on any problems!). If you're fetching a new installer (ramdisk kernel, install55.iso, floppy*.fs, etc) you can verify the signature of that file before using it. Also it should go without saying, if you use the untar sets on a running system method, checking those sets is your responsibility, see signify(1)'s EXAMPLES section for information about how to do this. What about as TXT record for dns (in combination with DNSSEC) as alternative for getting the key? :) jirib
Re: signed packages
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 tinfoil hats kids. OMG there's no replies.. The NSA programmed the 'bot to not respond to this topic!
Re: signed base installs
On Wed, Jan 22, 2014 at 15:33, Christian Weisgerber wrote: Theo de Raadt dera...@cvs.openbsd.org 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 mount point is somewhat annoying. I don't like to fragment the available disk space on small machines that run off a CF or similar and where I may not even bother to create a user. If you download the sets ahead of time and install from disk, it should verify them without the requirement for /home. Hopefully we can improve the installer's ability to locate free space. Right now, it downloads everything to avoid the situation where half the sets install, but then one fails, and you're left with a half upgraded system.
Re: 5.5beta wierds
On Wed, 22 Jan 2014 10:26:47 +0100, Otto Moerbeek wrote: yeah, I first had that and then deleted it. OK. - todd
Re: signed packages
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 whose certificates are magically transported into operating systems and placed in that special place in our hearts where no file could ever be modified... They also suggest we should move the machines that generate the releases into of those same castles where power is cheaper to save money... 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 tinfoil hats kids. Bob, There were lots of e-mails through the years on misc, some of myself, that asked for more, how can I say, trustiness on the getting the source and/or, just using the binaries provided by OpenBSD. I believe that signify helps a lot on this. I took a look at the code and it's simple and beautiful. I myself download the installXX.iso and source code from different mirrors/anoncvs, and using different internet links, just to be sure that things are in order. I'll be even more paranoid with the next release to make sure I have the right keys, both for 5.5 and the ones that follow. Tinfoil hats apart, I believe that with the interdiction programs that NSA has, and maybe also other governments, CD's can not be entitled with the same trust as before. I believe that DNSSEC is just one of the many things that could be done to make this trust more easy to obtain and verify. I've been living without it anyway. Cheers, -- Giancarlo Razzolini GPG: 4096R/77B981BC
Re: signed packages
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 fit pretty easily across the bottom of a shirt in a font size (36) that's legible without dominating the whole shirt.
Re: signed packages
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 t...@tedunangst.com wrote: 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 fit pretty easily across the bottom of a shirt in a font size (36) that's legible without dominating the whole shirt.
Re: signed packages
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 systems... Please get our your tinfoil hats kids. OMG there's no replies.. The NSA programmed the 'bot to not respond to this topic! That's probably because the NSA are now so high on magic pixie dust from your previous post you sent them. When they come down the 'bot will respond. Ian McWilliam
Re: Buggy i386 install55.iso
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 Edmonton. Doing install (not doing upgrade etc) process gets to the point of loading sets and crashes with a 5 line message that disappears before I can memorise it and a faster small message that gets away from me. Tested on two disparate machines - same result. Repeatability 100%. I'll try an amd64 and report result. /R/ *** NOTE *** Please DO NOT CC me. I am subscribed to the list. Mail to the sender address that does not originate at the list server is tarpitted. The reply-to: address is provided for those who feel compelled to reply off list. Thankyou. Rod/ --- This life is not the real thing. It is not even in Beta. If it was, then OpenBSD would already have a man page for it. *** NOTE *** Please DO NOT CC me. I am subscribed to the list. Mail to the sender address that does not originate at the list server is tarpitted. The reply-to: address is provided for those who feel compelled to reply off list. Thankyou. Rod/ --- This life is not the real thing. It is not even in Beta. If it was, then OpenBSD would already have a man page for it.
pf_check_proto_cksum(): simplify ICMP checksum verification
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
===
RCS file: /cvs/src/sys/net/pf.c,v
retrieving revision 1.865
diff -u -p -U10 -r1.865 pf.c
--- pf.c22 Jan 2014 04:33:34 - 1.865
+++ pf.c22 Jan 2014 22:33:23 -
@@ -5875,37 +5875,25 @@ pf_check_proto_cksum(struct pf_pdesc *pd
return (0);
}
if (pd-m-m_pkthdr.csum_flags flag_bad || off sizeof(struct ip) ||
pd-m-m_pkthdr.len off + len) {
pd-csum_status = PF_CSUM_BAD;
return (1);
}
switch (af) {
#ifdef INET
case AF_INET:
- if (p == IPPROTO_ICMP) {
- if (pd-m-m_len off) {
- pd-csum_status = PF_CSUM_BAD;
- return (1);
- }
- pd-m-m_data += off;
- pd-m-m_len -= off;
- sum = in_cksum(pd-m, len);
- pd-m-m_data -= off;
- pd-m-m_len += off;
- } else {
- if (pd-m-m_len sizeof(struct ip)) {
- pd-csum_status = PF_CSUM_BAD;
- return (1);
- }
- sum = in4_cksum(pd-m, p, off, len);
+ if (pd-m-m_len sizeof(struct ip)) {
+ pd-csum_status = PF_CSUM_BAD;
+ return (1);
}
+ sum = in4_cksum(pd-m, (p == IPPROTO_ICMP ? 0 : p), off, len);
break;
#endif /* INET */
#ifdef INET6
case AF_INET6:
if (pd-m-m_len sizeof(struct ip6_hdr)) {
pd-csum_status = PF_CSUM_BAD;
return (1);
}
sum = in6_cksum(pd-m, p, off, len);
break;
