OK, turing.

<- leave blank

Fri Jun 24 08:02:24 EDT 2022

/tmp ; cat f.c; 8c f.c; 8l f.8; 8.out; webpaste /dev/text
#include <u.h>
#include <libc.h>

typedef struct List List;
struct List {
	int n;
	List *next;

main(int argc, char *argv[])
	List *l;
	int wtf[1];

	print("%p\n", &l);
	print("%p\n", &l->next);
	print("%p\n", &l->next->next);
8.out 1712: suicide: sys: trap: fault read addr=0x4 pc=0x0000105c

Fri Jun 24 07:58:44 EDT 2022
/tmp ; cat f.c && 8c f.c && 8l f.8 && 8.out
#include <u.h>
#include <libc.h>

typedef struct List List;
struct List {
	int n;
	List *next;

main(int argc, char *argv[])
	List *l;

	print("%p\n", &l);
	print("%p\n", &l->next);
	print("%p\n", &l->next->next);
8.out 1618: suicide: sys: trap: fault read addr=0x4 pc=0x0000105c
/tmp ; cat /dev/text | webpaste
webwaste: './webwaste' file not found
/tmp ; cat /dev/text | webpaste

Thu Jun 23 20:14:25 EDT 2022
Date: Thu, 01 Feb 2018 09:29:21 +0000
From: Daniel Margolis <dmargolis@google.com>
To: khm@sciops.net
Cc: draft-ietf-uta-mta-sts@ietf.org
Subject: Re: draft-ietf-uta-mta-sts

[-- OpenSSL output follows (current time: Thu Jun 23 17:14:01 2022) --]
[-- End of OpenSSL output --]

[-- The following data is signed --]


You're definitely making a sane observation.  This came up a bunch of times
in the past; in fact, I wrote a short (and really now quite outdated) FAQ
on this at one point in the now-distant past:


We did originally want to use DNS; in fact, when we were originally
exploring ideas, I had originally wanted not to use HTTP at all, and just
kind of use some plaintext DNS something something (say, stick a signed
policy with the signature in a TXT record)--but that's not really feasible,
since many DNS servers/hosts/infrastructure caps the size of/number of TXT
records, so it's hard to fit the whole cert chain to use CA-signed certs to
sign random blobs like that.  So then the next idea was to allow people to
optionally use DNSSEC to broadcast their signature--but if you can do
DNSSEC, why not just do DANE?

Ultimately, as problematic as it is in some ways to require web services to
use STS, our conclusion (documented quite heavily in the archives of the
list, though I can hardly fault you for not wanting to read through it
all!) was that HTTPS was fairly accessible, with fairly well-understood
semantics of cert validity and so forth.

Hope that helps.


On Thu, Feb 1, 2018 at 2:51 AM Kurt H Maier <khm@sciops.net> wrote:

> Is it the intention of this document to effectively require all
> compliant MTAs to also implement web services?  Is there a particular
> reason that HTTPS is the only supported policy transport?  Would the
> working group be amenable to exploring DNS-only methods for expressing
> MTA-STS policy?
> Thanks,
> khm

[-- End of signed data --]

Thu Jun 23 20:12:41 EDT 2022
Date: Fri, 02 Feb 2018 07:12:55 +0000
From: Daniel Margolis <dmargolis@google.com>
To: khm@sciops.net
Cc: draft-ietf-uta-mta-sts@ietf.org
Subject: Re: draft-ietf-uta-mta-sts

[-- OpenSSL output follows (current time: Thu Jun 23 17:11:17 2022) --]
[-- End of OpenSSL output --]

[-- The following data is signed --]

On Thu, Feb 1, 2018 at 7:28 PM Kurt H Maier <khm@sciops.net> wrote:

> On Thu, Feb 01, 2018 at 06:05:42PM +0000, Daniel Margolis wrote:
> >
> > I may be misunderstanding you, but absent DNSSEC, it *is* necessary to
> > establish that mx.isp.net is the correct MX for example.com.  Merely
> > authenticating the MX for its hostname is insufficient to prevent a
> > man-in-the-middle attack, since injecting fake MX records is a trivial
> > workaround, right?
> >
> Yes, absent DNSSEC, DNS is not secured.  The objection here is that
> instead of recommending the security features of the already-involved
> DNS services, you're recommending a secondary (tertiary?) protocol that
> also does not solve the problem.  If you can inject a fake MX record,
> you can inject a fake A record, and authenticate on bad well-known data.

To be clear, if you inject a fake A record, the MTA-STS client will reject
the policy served because the "policy.example.com" MITM won't have a valid
certificate for example.com.  (Assuming, of course, that they don't have a
valid certificate.) So instead of authenticating the MX records directly,
we are in fact authenticating (via the CA signedness) the "acceptable
identities" of the MX hosts (which are themselves also required to be CA

So STS does not require trusted DNS, which is really a significant
motivator here.  Any changes that did not have those same security
properties in the absence of DNSSEC would be undesirable.

> > But I don't have a great answer for you beyond that, and I agree that
> it's
> > feasible to do it all with DNS, at least in concept.
> I beg you to consider reintroducing this as an option, even if it's just
> to serve the policy tuples.  That way we can fix the implicit TLS
> situation with SMTP and have a proper, complete solution.
> > Zoomed out a bit, I think the big challenge with all of this is
> > retrofitting.  HTTP is in some sense easier, because it's (usually) an
> > interactive user-agent.  So if you fall back to insecure (or encounter
> cert
> > problems) you can tell the user and ask them what to do.  For decades,
> > "proper functioning" of HTTPS has been basically to show the user in the
> > event of a downgrade attack (and, like, hope the user notices, which is
> > often futile).
> Yes, and machines are much more reliable about rejecting situations
> they've been programmed to reject.  But in this case they're not really
> being given the opportunity here; it's just getting offloaded to a
> client protocol in another stack.  SMTP already has error reporting
> mechanisms and extending with a 'needs tls' error message is trivial and
> simple.
> Thanks,
> khm

[-- End of signed data --]

Thu Jun 23 18:27:43 EDT 2022
diff 7ca997bf7efdca16416b22488ebc7b70c419fd44 uncommitted
--- a//sys/include/libsec.h
+++ b//sys/include/libsec.h
@@ -374,6 +374,7 @@
 int pkcs1unpadbuf(uchar *buf, int len, mpint *modulus, int blocktype);
 int asn1encodeRSApub(RSApub *pk, uchar *buf, int len);
 int asn1encodeRSApriv(RSApriv *k, uchar *buf, int len);
+int asn1encodeRSApubSPKI(RSApub *pk, uchar *buf, int len);
 int asn1encodedigest(DigestState* (*fun)(uchar*, ulong, uchar*, DigestState*),
			uchar *digest, uchar *buf, int len);

--- a//sys/src/cmd/auth/rsa2asn1.c
+++ b//sys/src/cmd/auth/rsa2asn1.c
@@ -6,11 +6,12 @@
 #include "rsa2any.h"

 int privatekey = 0;
+char *format = "pkcs1";

- fprint(2, "usage: auth/rsa2asn1 [-a] [file]\n");
+ fprint(2, "usage: auth/rsa2asn1 [-a] [-f fmt] [file]\n");

@@ -25,6 +26,9 @@
	case 'a':
		privatekey = 1;
+ case 'f':
+ format = EARGF(usage());
+ break;
@@ -32,14 +36,25 @@
	if(argc > 1)

+ n = -1;
	if((k = getrsakey(argc, argv, privatekey, nil)) == nil)
- if((n = asn1encodeRSApriv(k, buf, sizeof(buf))) < 0)
- sysfatal("asn1encodeRSApriv: %r");
+ if(strcmp(format, "pkcs1") == 0)
+ n = asn1encodeRSApriv(k, buf, sizeof(buf));
+ else
+ sysfatal("unknown format %s", format);
+ if(n < 0)
+ sysfatal("encode: %r");
- if((n = asn1encodeRSApub(&k->pub, buf, sizeof(buf))) < 0)
- sysfatal("asn1encodeRSApub: %r");
+ if(strcmp(format, "pkcs1") == 0)
+ n = asn1encodeRSApub(&k->pub, buf, sizeof(buf));
+ else if(strcmp(format, "spki") == 0)
+ n = asn1encodeRSApubSPKI(&k->pub, buf, sizeof(buf));
+ else
+ sysfatal("unknown format %s", format);
+ if(n < 0)
+ sysfatal("encode: %r");
	if(write(1, buf, n) != n)
		sysfatal("write: %r");
--- a//sys/src/libsec/port/x509.c
+++ b//sys/src/libsec/port/x509.c
@@ -788,6 +788,7 @@

	p = &uc;
	err = enc(&p, e, 1);
+ *pbytes = nil;
	if(err == ASN_OK) {
		ans = newbytes(p-&uc);
		p = ans->data;
@@ -2900,6 +2901,32 @@
	memmove(buf, b->data, len = b->len);
+ return len;
+asn1encodeRSApubSPKI(RSApub *pk, uchar *buf, int len)
+ Bytes *b, *k;
+ Elem e;
+ k = encode_rsapubkey(pk);
+ if(k == nil)
+ return -1;
+ e = mkseq(
+ mkel(mkalg(ALG_rsaEncryption),
+ mkel(mkbits(k->data, k->len),
+ nil)));
+ encode(e, &b);
+ freebytes(k);
+ if(b == nil)
+ return -1;
+ if(b->len > len){
+ freebytes(b);
+ werrstr("buffer too small");
+ return -1;
+ }
+ memmove(buf, b->data, len = b->len);
	return len;

Thu Jun 23 12:18:27 EDT 2022

#!/bin/sh -e

if [ 0 -ne `id -u` ]; then
  echo "This script needs root access" >&2
  exit 1

if ! [ -d "$1" ] || [ x-h = x"$*" ] || [ x--help = x"$*" ]; then
  echo "Usage: ${0##*/} <chroot_directory>" >&2
  exit 1

if [ x1 = x`sysctl -ne kernel.grsecurity.chroot_deny_chmod` ]; then
  echo "Warning: can't suid/sgid inside chroot" >&2
if [ x1 = x`sysctl -ne kernel.grsecurity.chroot_deny_mknod` ]; then
  echo "Warning: can't mknod inside chroot" >&2
if [ x1 = x`sysctl -ne kernel.grsecurity.chroot_deny_mount` ]; then
  echo "Warning: can't mount inside chroot" >&2
if [ x1 = x`sysctl -ne kernel.grsecurity.chroot_deny_chroot` ]; then
  echo "Warning: can't chroot inside chroot" >&2

cd "$1"
if ! [ -d ./etc ]; then
  echo "No etc directory inside $1" >&2
  exit 1

umount_all() {
  case $MOUNTED in
  shm\ *) if [ -L ./dev/shm ]; then
	    umount ./`readlink ./dev/shm`
	    umount ./dev/shm
	  MOUNTED=${MOUNTED#shm };;
  case $MOUNTED in
  run\ *) umount ./run
	  MOUNTED=${MOUNTED#run };;
  case $MOUNTED in
  tmp\ *) umount ./tmp
	  MOUNTED=${MOUNTED#tmp };;
  case $MOUNTED in
  proc\ *) umount ./proc
	  MOUNTED=${MOUNTED#proc };;
  case $MOUNTED in
  sys\ *) umount ./sys
	  MOUNTED=${MOUNTED#sys };;
  case $MOUNTED in
  pts\ *) umount ./dev/pts
	  MOUNTED=${MOUNTED#pts };;
  case $MOUNTED in
  dev\ *) umount ./dev
	  MOUNTED=${MOUNTED#dev };;
trap 'umount_all' EXIT

#mkdir -p ./etc ./dev/pts ./sys ./proc ./tmp ./run ./boot ./root

cp -iL /etc/resolv.conf ./etc/ || true # if ^C, will cancel script

mount --bind /dev ./dev

mount -t devpts devpts ./dev/pts -o nosuid,noexec

mount -t sysfs sys ./sys -o nosuid,nodev,noexec,ro

mount -t proc proc ./proc -o nosuid,nodev,noexec

mount -t tmpfs tmp ./tmp -o mode=1777,nosuid,nodev,strictatime
mount -t tmpfs run ./run -o mode=0755,nosuid,nodev
if [ -L ./dev/shm ]; then
  mkdir -p ./`readlink ./dev/shm`
  mount -t tmpfs shm ./`readlink ./dev/shm` -o mode=1777,nosuid,nodev
  #mkdir -p ./dev/shm
  mount -t tmpfs shm ./dev/shm -o mode=1777,nosuid,nodev

case $1 in
  -l) shift;;
  -l*) one=${1#-l}; shift; set -- -"$one" "$@";;
chroot . /usr/bin/env -i SHELL=/bin/sh HOME=/root TERM="$TERM" \
  PATH=/usr/sbin:/usr/bin:/sbin:/bin PS1='chroot # ' /bin/sh -l "$@"

# are USER and LOGNAME set automatically?
# perhaps: source /etc/profile && export PS1="chroot $PS1"

Wed Jun 22 10:03:28 EDT 2022

Tue Jun 21 21:33:47 EDT 2022
From: Rob Pike <robpike@gmail.com>
Date: Wed, 22 Jun 2022 10:48:24 +1000
To: Larry McVoy <lm@mcvoy.com>
CC: The Eunuchs Hysterical Society <tuhs@tuhs.org>
Subject: [TUHS] Re: forgotten versions

Plan 9 used Datakit as its network for quite a while.  The Gnot terminals
had an INCON interface, a megabit (approximately) twisted pair adjunct to
Datakit.  I had an INCON link running over a T-1 link to my house - great
excitement back in the day.  (The kernel downloaded over the line and booted
the machine up to the window system - there was no local disk - from power
up, in 7 seconds.) NJ Bell needed to install a new nitrogen-pressurized
26-pair cable, supported by a new telephone pole, to set it up, because I
had already used up all available pairs on the existing line to my house.
All included at no extra cost.  (You pay for the service, not its

When the internet became unavoidable, we used Plan 9's import mechanism to
import the single external TCP/IP interface from our gateway machine, over
Datakit, to the Gnots.  We did the same, but importing now over IL (an
ethernet protocol built by Phil Winterbottom) when our terminals became PCs.

That's how I remember it, at least, but I might have got some details
wrong.  I think much of this is covered in


On Wed, Jun 22, 2022 at 10:13 AM Larry McVoy <lm@mcvoy.com> wrote:

> On Tue, Jun 21, 2022 at 05:56:02PM -0600, Jacob Moody wrote:
> > I recently stumbled across the existence of datakit
> > when going through the plan9foundation source archives.
> > Would be curious to hear more about its involvement
> > with plan9.
> Pretty sure datakit predated Plan 9, didn't Greg Chesson work on that?
> He was my mentor at SGI, my memory is datakit was sort of early on in
> his career and then he did XTP, which nobody knows about but I believe
> is still used by the military.
> Unless the early Bell Labs datakit and the Plan 9 datakit are different
> things.

Tue Jun 21 10:26:16 EDT 2022
#include <libc.h>
#include <draw.h>
#include <geometry.h>

main(int argc, char** argv){

	Space q = (Space){


Mon Jun 20 23:31:48 EDT 2022
    0:d=0 hl=4 l= 605 cons: SEQUENCE
    4:d=1 hl=2 l= 1 prim: INTEGER :00
    7:d=1 hl=3 l= 129 prim: INTEGER
  139:d=1 hl=2 l= 3 prim: INTEGER :010001
  144:d=1 hl=3 l= 128 prim: INTEGER
  275:d=1 hl=2 l= 65 prim: INTEGER
  342:d=1 hl=2 l= 65 prim: INTEGER
  409:d=1 hl=2 l= 65 prim: INTEGER
  476:d=1 hl=2 l= 64 prim: INTEGER
  542:d=1 hl=2 l= 65 prim: INTEGER

Mon Jun 20 21:25:04 EDT 2022

     SRV(3) SRV(3)

	  srv - server registry

	  bind #s /srv


	  The srv device provides a tree of directories holding
	  already-open channels to services.  In effect, srv is a bul-
	  letin board on which processes may post open file descrip-
	  tors to make them available to other processes.

	  To install a channel, create a new file such as /srv/myserv
	  and then write a text string (suitable for strtoul; see
	  atof(2)) giving the file descriptor number of an open file.
	  Any process may then open /srv/myserv to acquire another
	  reference to the open file that was registered.

	  An entry in srv holds a reference to the associated file
	  even if no process has the file open.  Removing the file
	  from /srv releases that reference.

	  It is an error to write more than one number into a server
	  file, or to create a file with a name that is already being

	  Opening the clone file allocates a new service directory.
	  Reading clone returns the id of the new directory.  This new
	  service directory can then be accessed at /srv/id.  Directo-
	  ries are recursable; each new servive directory contains its
	  own clone file.

	  To drop one end of a pipe into /srv, that is, to create a
	  named pipe:

	       int fd, p[2];
	       char buf[32];

	       fd = create("/srv/namedpipe", OWRITE, 0666);
	       fprint(fd, "%d", p[0]);
	       fprint(p[1], "hello");

	  At this point, any process may open and read /srv/namedpipe
	  to receive the hello string.  Data written to /srv/namedpipe
	  can be received by executing

	       read(p[1], buf, sizeof buf);

	  in the above process.


prev | next