From 041eafaf6a2fa03f1603f294e85204602029feb5 Mon Sep 17 00:00:00 2001 From: John-Mark Gurney Date: Sun, 18 Apr 2021 19:22:06 -0700 Subject: [PATCH] a bunch of formatting fixups... --- content/2014/03/ctf-armeb-debugging.html | 6 +- ...uilding-bhyve-images-using-makefs-and.html | 8 +-- ...ml-schema-validation-for-command-line.html | 4 +- .../adventures-in-autobahnwamp-security.html | 2 +- content/2018/03/unusable-insecurity.html | 7 ++- .../2018/07/making-freebsd-magnet-links.html | 60 ++++++++++--------- 6 files changed, 46 insertions(+), 41 deletions(-) diff --git a/content/2014/03/ctf-armeb-debugging.html b/content/2014/03/ctf-armeb-debugging.html index a59630b..588d753 100644 --- a/content/2014/03/ctf-armeb-debugging.html +++ b/content/2014/03/ctf-armeb-debugging.html @@ -22,7 +22,7 @@ r261788), but that didn't help as there is no kernel gdb support on armeb. As I'm doing this debugging over the network, I can't dump a core. -I didn't feel like hand decoding a struct vm_page, so I thought of other +I didn't feel like hand decoding a `struct vm_page`, so I thought of other methods, and one way is to use CTF to parse the data type and decode the data. I know python and ctypes, so I decided to wrap libctf and see what I could do. @@ -54,7 +54,7 @@ ValueError: '/tmp/avila.ctf': File is not in CTF or ELF format ``` Hmm, why is that? Well, it turns out that the endian of the CTF data -is wrong. The magic is `cf f1`, but the magic on amd64 is f1 cf, it's +is wrong. The magic is `cf f1`, but the magic on amd64 is `f1 cf`, it's endian swapped. That's annoying. After spending some time trying to build an cross shared version of libctf, I find that it has the same issue. @@ -87,7 +87,7 @@ arch's pointer sizes for `CTF_K_POINTER` types, which means that pointers appear to be 8 bytes in size instead of the correct 4 bytes. A little more hacking on the ctf.py script to force all pointers to be 4 bytes, and a little help to convert ddb output to a string and finally, I have -a dump of the struct vm_page that I was trying to get all along: +a dump of the struct vm_page that I was trying to get all along: ``` {'act_count': '\x00', 'aflags': '\x00', diff --git a/content/2014/10/building-bhyve-images-using-makefs-and.html b/content/2014/10/building-bhyve-images-using-makefs-and.html index a1e45d4..5ce926e 100644 --- a/content/2014/10/building-bhyve-images-using-makefs-and.html +++ b/content/2014/10/building-bhyve-images-using-makefs-and.html @@ -16,7 +16,7 @@ testing. EDIT: Anish Gupta did the work that Neel Natu commited. Thanks Anish! -I had previously built images using makefs and mkimg for a CF card for +I had previously built images using `makefs` and `mkimg` for a CF card for use in another machine, so being able to build images to use with bhyve makes sense. @@ -35,9 +35,9 @@ along with a completed buildworld and buildkernel. Then follow these steps: 3. Make a directory with your custom configuration files. The basics are `/etc/rc.conf` and `/etc/fstab` and you might want `/firstboot` on - there too. You will also need a METALOG file which contains the - permissions for the files. This is just a standard mtree file, so - you could use mtree to generate this instead of creating it by hand. + there too. You will also need a `METALOG` file which contains the + permissions for the files. This is just a standard `mtree` file, so + you could use `mtree` to generate this instead of creating it by hand. The file contents are below. 4. Build the ufs image using the `makeroot.sh` script in the src tree at `tools/tools/makeroot/makeroot.sh`: 

diff --git a/content/2015/05/xml-schema-validation-for-command-line.html b/content/2015/05/xml-schema-validation-for-command-line.html
index 9eaa787..22a5278 100644
--- a/content/2015/05/xml-schema-validation-for-command-line.html
+++ b/content/2015/05/xml-schema-validation-for-command-line.html
@@ -15,12 +15,12 @@ to specify a single schema file.  If you have an XML document that
 contains more than one name space this doesn't work too well as often,
 each name space is in a separate schema file.
 
-The XML document has xmlns attributes which use a URI as the identifier.
+The XML document has `xmlns` attributes which use a URI as the identifier.
 These URIs are for identifing it, and not a URL, so not able to be used.
 In fact, different cases in the URIs specify different name spaces even
 in the "host" part, though that is not the case with URLs.  In order for
 validators to find the schema, the attribute
-[xsi:schemaLocation](http://www.w3.org/TR/xmlschema-1/#schema-loc) is
+[xsi:schemaLocation](http://www.w3.org/TR/xmlschema-1/#schema-loc) is
 used to map the name space URIs to the URLs of the schema.
 
 The `xsi:schemaLocation` mapping is very simple.  It is simply a white
diff --git a/content/2017/09/adventures-in-autobahnwamp-security.html b/content/2017/09/adventures-in-autobahnwamp-security.html
index fa279e9..60bebf6 100644
--- a/content/2017/09/adventures-in-autobahnwamp-security.html
+++ b/content/2017/09/adventures-in-autobahnwamp-security.html
@@ -51,7 +51,7 @@ is WAMP-Cryptosign.
 After I got basic functionality working to make sure things would be
 workable w/ this framework, I decided to start working on the
 authentication piece.  First problem I ran into was that the AutoBahn|JS
-library does not support TLS channel binding.  There is a good read the
+library does not support TLS channel binding.  There is a good reason the
 library doesn't support it, and it's for a very bad reason.  There is
 no support in the browser [WebSocket API](https://www.w3.org/TR/websockets/)
 to query the channel binding information necessary.  The fact that
diff --git a/content/2018/03/unusable-insecurity.html b/content/2018/03/unusable-insecurity.html
index 1c8419b..a369d19 100644
--- a/content/2018/03/unusable-insecurity.html
+++ b/content/2018/03/unusable-insecurity.html
@@ -66,9 +66,10 @@ I'm clearly not the only one that has had issues configuring S3 buckets.
 The end of 2017 has shown a large number of organizations fail to
 properly secure their S3 buckets, leaving many terabytes of data open
 for public download. It is unacceptable that such a service is so
-difficult to configure. The site https://s3stupidity.com/ lists the
-large number of breaches, many of which are by large companies who
-should have the technical chops (and $$) to properly configure it.
+difficult to configure. The site
+[https://s3stupidity.com/](https://s3stupidity.com/) lists the large
+number of breaches, many of which are by large companies who should
+have the technical chops (and $$) to properly configure it.
 
 Security controls need to be simple and clear. Their descriptions need
 to be accurate and concise in what they do, and how they do it. Amazon
diff --git a/content/2018/07/making-freebsd-magnet-links.html b/content/2018/07/making-freebsd-magnet-links.html
index d2830ac..7ef6f0d 100644
--- a/content/2018/07/making-freebsd-magnet-links.html
+++ b/content/2018/07/making-freebsd-magnet-links.html
@@ -18,52 +18,52 @@ were command line based.  The other was there was/is no tool for
 extracting the info hash and building the magnet link.  There may be
 tools now, but I couldn't find any when I started 3 years ago.
 
-The following steps are based upon the recent release of FreeBSD 11.2-R,
+The following steps are based upon the recent release of FreeBSD 11.2‑R,
 adjust as necessary.
 
-1. Fetch FreeBSD into a directory (I create a per release directory).  There
+
    
+
  1. Fetch FreeBSD into a directory (I create a per release directory).  There
    are a few directories that you have mirror, I use wget for this.  The
    mirroring feature for wget isn't great.  After each command I have to
-   remove the `CHECKSUM.SHA256`, `CHECKSUM.SHA512` and `index.html*` files.
+   remove the CHECKSUM.SHA256, CHECKSUM.SHA512 and index.html* files.
    
    
    $ wget -c -r -l 1 -nd --limit-rate=800k https://download.freebsd.org/ftp/releases/ISO-IMAGES/11.2/
    $ wget -c -r -l 1 -nd --limit-rate=800k https://download.freebsd.org/ftp/releases/VM-IMAGES/11.2-RELEASE/aarch64/Latest/
    $ wget -c -r -l 1 -nd --limit-rate=800k https://download.freebsd.org/ftp/releases/VM-IMAGES/11.2-RELEASE/amd64/Latest/
    $ wget -c -r -l 1 -nd --limit-rate=800k https://download.freebsd.org/ftp/releases/VM-IMAGES/11.2-RELEASE/i386/Latest/
    
    
-2. Fetch the signature files:
+
  2. Fetch the signature files:
    
    
    $ wget https://www.freebsd.org/releases/11.2R/CHECKSUM.SHA512-FreeBSD-11.2-RELEASE-{amd64,i386,powerpc,powerpc-powerpc64,sparc64,arm64-aarch64}.asc
    $ wget https://www.freebsd.org/releases/11.2R/CHECKSUM.SHA512-FreeBSD-11.2-RELEASE-{amd64,i386,arm64-aarch64}-vm.asc
    $ wget https://www.freebsd.org/releases/11.2R/CHECKSUM.SHA512-FreeBSD-11.2-RELEASE-arm-armv6-{BANANAPI,BEAGLEBONE,CUBIEBOARD,CUBIEBOARD2,CUBBOX-HUMMINGBOARD,GUMSTIX,PANDABOARD,RPI-B,RPI2,WANDBOARD}.asc
    
    
-3. Verify the GPG key that signed the above files.  This is usually Glen
+
  3. Verify the GPG key that signed the above files.  This is usually Glen
    Barber's key, but not always.  I have met and verified his fingerprint
    in person,  If you have verified someone's key who has signed Glen's
    key, that is another good way.
-4. Verify the checksum files:
+
  4. Verify the checksum files:
    
    
    $ for i in *.asc; do gpg --verify $i; done
    You should see a bunch of lines like:
    Warning: using insecure memory!
    gpg: Signature made Fri Jun 22 09:33:50 2018 PDT
    gpg:                using RSA key 0x031458A5478FE293
-   gpg: Good signature from "Glen Barber " [full]
-   gpg:                 aka "Glen Barber " [full]
-   gpg:                 aka "Glen Barber " [full]
-   gpg:                 aka "Glen Barber " [unknown]
+   gpg: Good signature from "Glen Barber <gjb@FreeBSD.org>" [full]
+   gpg:                 aka "Glen Barber <glen.j.barber@gmail.com>" [full]
+   gpg:                 aka "Glen Barber <gjb@glenbarber.us>" [full]
+   gpg:                 aka "Glen Barber <gjb@keybase.io>" [unknown]
    gpg: WARNING: not a detached signature; file 'CHECKSUM.SHA512-FreeBSD-11.2-RELEASE-amd64-vm' was NOT verified!
-   
    
-   The last line can be ignored.  The non-`.asc` files were d/l'd and will
-   not be used.  Make sure that all of the files report Good signature.
-5. In the past I have used BitTornado for other things, so I ended up
+
The last line can be ignored. The non-.asc files were d/l'd and will + not be used. Make sure that all of the files report Good signature. +
  • In the past I have used BitTornado for other things, so I ended up using it as the basis to make the tool for creating trackerless torrent files. The modifications were simple. It appears that the original BitTornado CVS tree is off-line (anyways, it was served insecurely), but it looks like - [effigies/BitTornado](https://github.com/effigies/BitTornado) is + effigies/BitTornado is similar enough that it could be modified and used. I copied - `btmakemetafile.py` to `btmaketrackerless.py` and applied the following + btmakemetafile.py to btmaketrackerless.py and applied the following patch: 
    
    $ diff -u btmakemetafile.py btmaketrackerless.py 
@@ -73,11 +73,11 @@ adjust as necessary.
     def prog(amount):
         print '%.1f%% complete\r' % (amount * 100),
 
-   -if len(argv) < 3:
-   +if len(argv) < 2:
+   -if len(argv) < 3:
+   +if len(argv) < 2:
         a,b = split(argv[0])
-   -    print 'Usage: ' + b + '   [file...] [params...]'
-   +    print 'Usage: ' + b + '  [file...] [params...]'
+   -    print 'Usage: ' + b + ' <trackerurl> <file> [file...] [params...]'
+   +    print 'Usage: ' + b + ' <file> [file...] [params...]'
         print
         print formatDefinitions(defaults, 80)
         print_announcelist_details()
@@ -97,9 +97,9 @@ adjust as necessary.
    If you notice, the only thing that is done is to drop the first argument, - and instead of passing it into `make_meta_file`, a `None` is passed + and instead of passing it into make_meta_file, a None is passed instead. This will simply not add trackers to the torrent file. -6. I then run the following script to verify the downloaded files, and +
  • I then run the following script to verify the downloaded files, and generate the torrent files: 
    
    $ cat cmp.sh 
@@ -112,7 +112,7 @@ adjust as necessary.
    # wget https://www.freebsd.org/releases/11.2R/CHECKSUM.SHA512-FreeBSD-11.2-RELEASE-{amd64,i386,arm64-aarch64}-vm.asc
    # wget https://www.freebsd.org/releases/11.2R/CHECKSUM.SHA512-FreeBSD-11.2-RELEASE-arm-armv6-{BANANAPI,BEAGLEBONE,CUBIEBOARD,CUBIEBOARD2,CUBBOX-HUMMINGBOARD,GUMSTIX,PANDABOARD,RPI-B,RPI2,WANDBOARD}.asc
 
-   grep -h '^SHA512' CHECK*.asc | sed -e 's/SHA512 (\(.*\)) = \(.*\)/\2 \1/' | sort -k 2 > sha512.from.asc
+   grep -h '^SHA512' CHECK*.asc | sed -e 's/SHA512 (\(.*\)) = \(.*\)/\2 \1/' | sort -k 2 > sha512.from.asc
 
    while read hash fname; do
            if [ -e "$fname" ]; then
@@ -132,9 +132,9 @@ adjust as necessary.
                    echo missing "$fname"
                    exit 1
            fi
-   done < sha512.from.asc
+   done < sha512.from.asc
    -7. Once all the torrents have been generated, I then make the magnet +
  • Once all the torrents have been generated, I then make the magnet links: 
    
    $ cat btmakemagnet.sh 
@@ -156,8 +156,12 @@ adjust as necessary.
    }'
    done
    -8. I then create the magnet links file, and update the - [Torrents](https://wiki.freebsd.org/Torrents) wiki page. +
  • I then create the magnet links file, and update the + Torrents wiki page. + Sorry about the code formatting. I don't know how to make it look better -in blogger. +in blogger.The blog +no longer uses blogger.