Say you were writing a major standard, something implemented by thousands of companies. Say, one which specified, among other things, a format for public key files. Might it be appropriate to say "use a BER-encoded x509" certificate (with some (standard) x509 extensions)? Or would you:
- declare that you require a "special" binary format for your x509 certificates
- provide a large table breaking out an octet-by-octet dump (of an example BER certificate) as an example of how one would go about writing a certificate
- omit any explanation of what the various "key" or "header" values are in said binary dump (or how you calculate them from the x509 cert)
- leave it to the user to recognize that this "special" format must just be regular-old BER by the absurdly under-specified nature of the encoding
What implementer is going to write their own BER encoder/decoder? Why would you need to know the particular byte sequences in an example certificate? It would be a lot more useful to most people to include a PEM-format file and instructions on how to encode/decode it via openssh.
Comments
2010-08-31 12:04
That template db idea is prett y neat. I have to say it's get ting pretty annoying downloadi ng database backups and [...]
2010-08-23 20:57
Yeah, in a similar boat with t he code I write... upshot, I'v e got some pretty good compat code in snakeoil, just w [...]
2010-08-22 08:40
Yeah, that's what I started do ing (the function to convert t o bytes), as I support down to 2.4. Thing is this is [...]
2010-08-22 06:28
Your blog aparently likes does n't handle the less than char (<) conversion all that wel l.. everything following [...]
2010-08-22 06:24
The annoying thing about suppo rting both py2k and py3k is th at you wind up having to get r ather explicit about you [...]
2010-08-16 00:48
The measure of a man, I have a lways thought, was - that he l oved. And was loved.
2010-08-15 21:28
Hmm, hadn't realized that was what dpush was for. I guess I 'll have to make the trunk a b ranch rather than a chec [...]
2010-08-15 20:43
For what it's worth, newer ver sions of bzr-svn will not remo ve existing revisions from you r mainline unless you ex [...]
2010-08-15 20:40
bzr-svn supports not inserting any unusual revision properti es, it just means that pushing your bzr revisions into [...]
2010-08-15 18:21
Hmm, maybe I missed something there. Do you mean merge supp ort as in being able to pull f rom N branches into your [...]
2010-08-15 17:45
Lack of merge support kills th e main benefit of bzr-svn over just using svk I'd argue. Personally, I'm *extreme [...]
2010-08-15 11:46
You might want to check out hg subversion
2010-07-25 14:02
> and would have no Trac integ ration The trac-bzr plugin[ 1] seems to provide good integ ration between bzr and t [...]
2010-07-13 21:47
I've always been fascinated wi th the Asterisk AMI interface. So much so that I married tha t fascination with the [...]
2010-07-03 21:32
Yes, only references in dicti onaries are replaced, so hold ing references in lists, tuple s, etceteras keeps them alive.