boringssl

2558 Commits

61 Branches

23 Tags

513 MiB

Tag: Branch: Tree: master

Commit Graph

Author	SHA1	Message	Date
David Benjamin	6f4159567d	Start maintaining an AUTHORS file Following the guidance in https://opensource.google/documentation/reference/releasing/authors, start maintaining an AUTHORS file. Update all existing Google copyright lines to 'The BoringSSL Authors' per the document. This CL also changes the styling to match the new guidance: removed the '(c)' and the comma. All other existing copyright lines are left unmodified. Going forward, our preference will be that new contributions to BoringSSL use 'The BoringSSL Authors', optionally adding to the AUTHORS file if the contributor desires. To avoid being presumptuous, this CL does not proactively list every past contributor in the BoringSSL half of the AUTHORS file. Past contributors are welcome to send us a patch to be added, or request that we add you. (Listed or not, the commit log continues to be a more accurate record, and any existing non-Google copyright lines were left unmodified.) The OpenSSL half of the AUTHORS file is seeded with the contents of the current OpenSSL AUTHORS file, as of writing. The current contents in the latest revision of the 1.1.1 branch (b372b1f76450acdfed1e2301a39810146e28b02c) and master (d992e8729ee38b082482dc010e090bb20d1c7bd5) are identical, just formatted in text vs Markdown. Note when reviewing: CONTRIBUTING.md and AUTHORS contain non-mechanical changes. Bug: 364634028 Change-Id: I319d0ee63ec021ad85e248e8e3304b9cf9566681 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/74149 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>	5 months ago
David Benjamin	a942d57207	Support lists and code blocks in doc.go Our documentation comments already include examples of code blocks and lists, they just don't get rendered right. We also have things that were trying to be lists but aren't. Go ahead and add support for it, and fix the handful of list-like things that didn't get rendered as lists. I took inspiration from CommonMark (https://spec.commonmark.org/0.30/) to resolve questions such as whether blank lines are needed between lists, etc., but this does not support any kind of nesting and is still far from a CommonMark parser. Aligning with CommonMark leaves the door open to pulling in a real Markdown parser if we start to need too many features. I've also borrowed the "block" terminology from CommonMark. One ambiguity of note: whether lists may interrupt paragraphs (i.e. without a blank line in between) is a little thorny. If we say no, this doesn't work: Callers should heed the following warnings: 1) Don't use the function 2) Seriously, don't use this function 3) This function is a bad idea But if we say yes, this renders wrong: This function parses an X.509 certificate (see RFC 5280) into an X509 object. We have examples of both in existing comments, though we could easily add a blank line in the former or rewrap the latter. CommonMark has a discussion on this in https://spec.commonmark.org/0.30/#lists CommonMark says yes, but with a hack that only lists starting with 1 can interrupt paragraphs. Since we're unlikely to cite RFC 1, I've matched for now, but we may want to revisit this if it gets to be a pain. I could imagine this becoming a problem: This function, on success, does some stuff and returns 1. Otherwise, it returns 0. But that looks a little weird and we usually spell out "one" and "zero". I printed all the lists we detected in existing comments, and this has not happened so far. I've also required fewer spaces than CommonMark to trigger a code block. CommonMark uses four, but four spaces plus a leading "//" and a " " is quite a lot. For now I'm not stripping the spaces after the comment marker at comment extraction time and then requiring three spaces, so two spaces relative to normal text. This is mostly to match what we've currently been doing, but we can always change it and our comments later. Change-Id: Ic61a8e93491ed96aba755aec2a5f32914bdc42ae Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/64930 Reviewed-by: Bob Beck <bbe@google.com> Commit-Queue: David Benjamin <davidben@google.com>	1 year ago
Adam Langley	fb0c05cac2	acvp: add CMAC-AES support. Change by Dan Janni. Change-Id: I3f059e7b1a822c6f97128ca92a693499a3f7fa8f Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41984 Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: David Benjamin <davidben@google.com>	5 years ago

Author

SHA1

Message

Date

David Benjamin

6f4159567d

Start maintaining an AUTHORS file

Following the guidance in
https://opensource.google/documentation/reference/releasing/authors,
start maintaining an AUTHORS file.

Update all existing Google copyright lines to 'The BoringSSL Authors'
per the document. This CL also changes the styling to match the new
guidance: removed the '(c)' and the comma.

All other existing copyright lines are left unmodified. Going forward,
our preference will be that new contributions to BoringSSL use 'The
BoringSSL Authors', optionally adding to the AUTHORS file if the
contributor desires.

To avoid being presumptuous, this CL does *not* proactively list every
past contributor in the BoringSSL half of the AUTHORS file. Past
contributors are welcome to send us a patch to be added, or request that
we add you. (Listed or not, the commit log continues to be a more
accurate record, and any existing non-Google copyright lines were left
unmodified.)

The OpenSSL half of the AUTHORS file is seeded with the contents of the
current OpenSSL AUTHORS file, as of writing. The current contents in the
latest revision of the 1.1.1 branch
(b372b1f76450acdfed1e2301a39810146e28b02c) and master
(d992e8729ee38b082482dc010e090bb20d1c7bd5) are identical, just formatted
in text vs Markdown.

Note when reviewing: CONTRIBUTING.md and AUTHORS contain non-mechanical
changes.

Bug: 364634028
Change-Id: I319d0ee63ec021ad85e248e8e3304b9cf9566681
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/74149
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>

5 months ago

David Benjamin

a942d57207

Support lists and code blocks in doc.go

Our documentation comments already include examples of code blocks
and lists, they just don't get rendered right. We also have things that
were trying to be lists but aren't. Go ahead and add support for it, and
fix the handful of list-like things that didn't get rendered as lists.

I took inspiration from CommonMark (https://spec.commonmark.org/0.30/)
to resolve questions such as whether blank lines are needed between
lists, etc., but this does not support any kind of nesting and is still
far from a CommonMark parser. Aligning with CommonMark leaves the door
open to pulling in a real Markdown parser if we start to need too many
features. I've also borrowed the "block" terminology from CommonMark.

One ambiguity of note: whether lists may interrupt paragraphs (i.e.
without a blank line in between) is a little thorny. If we say no, this
doesn't work:

   Callers should heed the following warnings:
   1) Don't use the function
   2) Seriously, don't use this function
   3) This function is a bad idea

But if we say yes, this renders wrong:

   This function parses an X.509 certificate (see RFC
   5280) into an X509 object.

We have examples of both in existing comments, though we could easily
add a blank line in the former or rewrap the latter. CommonMark has a
discussion on this in https://spec.commonmark.org/0.30/#lists

CommonMark says yes, but with a hack that only lists starting with 1 can
interrupt paragraphs. Since we're unlikely to cite RFC 1, I've matched
for now, but we may want to revisit this if it gets to be a pain. I
could imagine this becoming a problem:

   This function, on success, does some stuff and returns
   1. Otherwise, it returns 0.

But that looks a little weird and we usually spell out "one" and "zero".
I printed all the lists we detected in existing comments, and this has
not happened so far.

I've also required fewer spaces than CommonMark to trigger a code block.
CommonMark uses four, but four spaces plus a leading "//" and a " " is
quite a lot. For now I'm not stripping the spaces after the comment
marker at comment extraction time and then requiring three spaces, so
two spaces relative to normal text. This is mostly to match what we've
currently been doing, but we can always change it and our comments
later.

Change-Id: Ic61a8e93491ed96aba755aec2a5f32914bdc42ae
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/64930
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>

1 year ago

Adam Langley

fb0c05cac2

acvp: add CMAC-AES support.

Change by Dan Janni.

Change-Id: I3f059e7b1a822c6f97128ca92a693499a3f7fa8f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41984
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>

5 years ago

3 Commits (master)