Mailing List Archive

mod_tls as experimental module?
How would you feel about adding mod_tls (https://github.com/abetterinternet/mod_tls) as an experimental module to Apache httpd?

For people who have not followed that development:
- it is a TLS 1.2/1.3 implementation based on rustls, https://github.com/rustls/rustls
- the C API is rustls-ffi, found at https://github.com/rustls/rustls-ffi
- it is itself written in C, linking all the Rust things from the rustls-ffi library
- it does not bring any Rust into our code base
- functionality wise, it is a clear subset of what mod_ssl offers via openssl
(e.g. no client certificates now and not as tweakable - at least for now)
- it can be co-loaded and co-used with mod_ssl on different ports or front-/backend roles
- performance-wise, according to my plain vanilla tests, it is on par with mod_ssl

The decision to offer it downstream is of course then made by the distros, as usual with experimental modules. And if and how it is then used rests with the users. It is an offered alternative for people.

What would be the benefit to the project?
- we offer people an alternative. If they feel the memory safety that Rust offers is important to them, they can do it with Apache httpd for the TLS stack.
- we could see how people react to this and adapt our TLS offering accordingly. It being experimental, we remain free to change it. Or remove it again.

Organizational Things:
- the development was done by myself
- the work was sponsored by the ISRG (https://www.abetterinternet.org), the org behind Let's Encrypt, as part of they "memory safety" initiative (https://www.memorysafety.org)


Feedback appreciated,

Stefan

PS. On a more personal note:
The way this project turned out was a clean separation between C and Rust. The API offered by rustls-ffi is colored by Rust's immutability/borrowed memory concepts, but there is nothing Rust special the C code needs to do. It remains C code. It remains in our core competence.

Working with the rustls people has been nice and productive. The only thing I can report is that they come from the client TLS side and specific server needs require some explaining. There are things we can offer to them here.

There are a lot of political things going on right now around OpenSSL and I definitely want to stay out of that. Again, we can offer this without having to switch ourself. Even better, customers can use this without needing to switch completely, as it co-exists. I think that fits into the concepts our server is designed with.

Thanks for your time.
Re: mod_tls as experimental module? [ In reply to ]
Coming back to this. Since there was no feedback on my post: are people
just too occupied/opposed/not interested?

Curious,
Stefan

> Am 18.11.2021 um 18:48 schrieb stefan@eissing.org:
>
> How would you feel about adding mod_tls (https://github.com/abetterinternet/mod_tls) as an experimental module to Apache httpd?
>
> For people who have not followed that development:
> - it is a TLS 1.2/1.3 implementation based on rustls, https://github.com/rustls/rustls
> - the C API is rustls-ffi, found at https://github.com/rustls/rustls-ffi
> - it is itself written in C, linking all the Rust things from the rustls-ffi library
> - it does not bring any Rust into our code base
> - functionality wise, it is a clear subset of what mod_ssl offers via openssl
> (e.g. no client certificates now and not as tweakable - at least for now)
> - it can be co-loaded and co-used with mod_ssl on different ports or front-/backend roles
> - performance-wise, according to my plain vanilla tests, it is on par with mod_ssl
>
> The decision to offer it downstream is of course then made by the distros, as usual with experimental modules. And if and how it is then used rests with the users. It is an offered alternative for people.
>
> What would be the benefit to the project?
> - we offer people an alternative. If they feel the memory safety that Rust offers is important to them, they can do it with Apache httpd for the TLS stack.
> - we could see how people react to this and adapt our TLS offering accordingly. It being experimental, we remain free to change it. Or remove it again.
>
> Organizational Things:
> - the development was done by myself
> - the work was sponsored by the ISRG (https://www.abetterinternet.org), the org behind Let's Encrypt, as part of they "memory safety" initiative (https://www.memorysafety.org)
>
>
> Feedback appreciated,
>
> Stefan
>
> PS. On a more personal note:
> The way this project turned out was a clean separation between C and Rust. The API offered by rustls-ffi is colored by Rust's immutability/borrowed memory concepts, but there is nothing Rust special the C code needs to do. It remains C code. It remains in our core competence.
>
> Working with the rustls people has been nice and productive. The only thing I can report is that they come from the client TLS side and specific server needs require some explaining. There are things we can offer to them here.
>
> There are a lot of political things going on right now around OpenSSL and I definitely want to stay out of that. Again, we can offer this without having to switch ourself. Even better, customers can use this without needing to switch completely, as it co-exists. I think that fits into the concepts our server is designed with.
>
> Thanks for your time.
>
Re: mod_tls as experimental module? [ In reply to ]
Possibly no strong opinions? +1 from me anyway.

How hard is it going to be to test in Travis?

On Wed, Nov 24, 2021 at 10:46:03AM +0100, stefan@eissing.org wrote:
> Coming back to this. Since there was no feedback on my post: are people
> just too occupied/opposed/not interested?
>
> Curious,
> Stefan
>
> > Am 18.11.2021 um 18:48 schrieb stefan@eissing.org:
> >
> > How would you feel about adding mod_tls (https://github.com/abetterinternet/mod_tls) as an experimental module to Apache httpd?
> >
> > For people who have not followed that development:
> > - it is a TLS 1.2/1.3 implementation based on rustls, https://github.com/rustls/rustls
> > - the C API is rustls-ffi, found at https://github.com/rustls/rustls-ffi
> > - it is itself written in C, linking all the Rust things from the rustls-ffi library
> > - it does not bring any Rust into our code base
> > - functionality wise, it is a clear subset of what mod_ssl offers via openssl
> > (e.g. no client certificates now and not as tweakable - at least for now)
> > - it can be co-loaded and co-used with mod_ssl on different ports or front-/backend roles
> > - performance-wise, according to my plain vanilla tests, it is on par with mod_ssl
> >
> > The decision to offer it downstream is of course then made by the distros, as usual with experimental modules. And if and how it is then used rests with the users. It is an offered alternative for people.
> >
> > What would be the benefit to the project?
> > - we offer people an alternative. If they feel the memory safety that Rust offers is important to them, they can do it with Apache httpd for the TLS stack.
> > - we could see how people react to this and adapt our TLS offering accordingly. It being experimental, we remain free to change it. Or remove it again.
> >
> > Organizational Things:
> > - the development was done by myself
> > - the work was sponsored by the ISRG (https://www.abetterinternet.org), the org behind Let's Encrypt, as part of they "memory safety" initiative (https://www.memorysafety.org)
> >
> >
> > Feedback appreciated,
> >
> > Stefan
> >
> > PS. On a more personal note:
> > The way this project turned out was a clean separation between C and Rust. The API offered by rustls-ffi is colored by Rust's immutability/borrowed memory concepts, but there is nothing Rust special the C code needs to do. It remains C code. It remains in our core competence.
> >
> > Working with the rustls people has been nice and productive. The only thing I can report is that they come from the client TLS side and specific server needs require some explaining. There are things we can offer to them here.
> >
> > There are a lot of political things going on right now around OpenSSL and I definitely want to stay out of that. Again, we can offer this without having to switch ourself. Even better, customers can use this without needing to switch completely, as it co-exists. I think that fits into the concepts our server is designed with.
> >
> > Thanks for your time.
> >
>
Re: mod_tls as experimental module? [ In reply to ]
> Am 24.11.2021 um 10:57 schrieb Joe Orton <jorton@redhat.com>:
>
> Possibly no strong opinions? +1 from me anyway.
>
> How hard is it going to be to test in Travis?

I have a test suite that can be added to our test/modules. Then
we need to bring the rust tool chain into the test image and
checkout/create the librustls.

I can start a docker image to see what that needs.

Kind Regards,
Stefan

>
> On Wed, Nov 24, 2021 at 10:46:03AM +0100, stefan@eissing.org wrote:
>> Coming back to this. Since there was no feedback on my post: are people
>> just too occupied/opposed/not interested?
>>
>> Curious,
>> Stefan
>>
>>> Am 18.11.2021 um 18:48 schrieb stefan@eissing.org:
>>>
>>> How would you feel about adding mod_tls (https://github.com/abetterinternet/mod_tls) as an experimental module to Apache httpd?
>>>
>>> For people who have not followed that development:
>>> - it is a TLS 1.2/1.3 implementation based on rustls, https://github.com/rustls/rustls
>>> - the C API is rustls-ffi, found at https://github.com/rustls/rustls-ffi
>>> - it is itself written in C, linking all the Rust things from the rustls-ffi library
>>> - it does not bring any Rust into our code base
>>> - functionality wise, it is a clear subset of what mod_ssl offers via openssl
>>> (e.g. no client certificates now and not as tweakable - at least for now)
>>> - it can be co-loaded and co-used with mod_ssl on different ports or front-/backend roles
>>> - performance-wise, according to my plain vanilla tests, it is on par with mod_ssl
>>>
>>> The decision to offer it downstream is of course then made by the distros, as usual with experimental modules. And if and how it is then used rests with the users. It is an offered alternative for people.
>>>
>>> What would be the benefit to the project?
>>> - we offer people an alternative. If they feel the memory safety that Rust offers is important to them, they can do it with Apache httpd for the TLS stack.
>>> - we could see how people react to this and adapt our TLS offering accordingly. It being experimental, we remain free to change it. Or remove it again.
>>>
>>> Organizational Things:
>>> - the development was done by myself
>>> - the work was sponsored by the ISRG (https://www.abetterinternet.org), the org behind Let's Encrypt, as part of they "memory safety" initiative (https://www.memorysafety.org)
>>>
>>>
>>> Feedback appreciated,
>>>
>>> Stefan
>>>
>>> PS. On a more personal note:
>>> The way this project turned out was a clean separation between C and Rust. The API offered by rustls-ffi is colored by Rust's immutability/borrowed memory concepts, but there is nothing Rust special the C code needs to do. It remains C code. It remains in our core competence.
>>>
>>> Working with the rustls people has been nice and productive. The only thing I can report is that they come from the client TLS side and specific server needs require some explaining. There are things we can offer to them here.
>>>
>>> There are a lot of political things going on right now around OpenSSL and I definitely want to stay out of that. Again, we can offer this without having to switch ourself. Even better, customers can use this without needing to switch completely, as it co-exists. I think that fits into the concepts our server is designed with.
>>>
>>> Thanks for your time.
>>>
>>
>
Re: mod_tls as experimental module? [ In reply to ]
Hi Stefan,

sorry for the lateness..

On Wed, Nov 24, 2021 at 10:46 AM stefan@eissing.org <stefan@eissing.org> wrote:
>
> Coming back to this. Since there was no feedback on my post: are people
> just too occupied/opposed/not interested?

I looked at the code diagonally and it looks good to me (I like it and
the safety guarantees of rust), thanks for the good work!
+1 for experimental which will give us some margin.

However what would be a discussion without a naming dispute, mod_rustls? :p
(no strong opinion of course..).

Cheers;
Yann.
Re: mod_tls as experimental module? [ In reply to ]
On Wed, Nov 24, 2021 at 11:19:17AM +0100, Yann Ylavic wrote:
> However what would be a discussion without a naming dispute, mod_rustls? :p

Agreed. At least as long as it's an experimental module. If it ever
moves beyond experimental, then a rename back to mod_tls might make
sense.

vh

Mads Toftum
--
http://flickr.com/photos/q42/
Re: mod_tls as experimental module? [ In reply to ]
On 18 Nov 2021, at 19:48, stefan@eissing.org wrote:

> How would you feel about adding mod_tls (https://github.com/abetterinternet/mod_tls) as an experimental module to Apache httpd?

Having more choice is excellent.

> For people who have not followed that development:
> - it is a TLS 1.2/1.3 implementation based on rustls, https://github.com/rustls/rustls
> - the C API is rustls-ffi, found at https://github.com/rustls/rustls-ffi
> - it is itself written in C, linking all the Rust things from the rustls-ffi library
> - it does not bring any Rust into our code base
> - functionality wise, it is a clear subset of what mod_ssl offers via openssl
> (e.g. no client certificates now and not as tweakable - at least for now)

Client certs is a must for me. I know that they’re political, but my clients in finance don’t care.

> - it can be co-loaded and co-used with mod_ssl on different ports or front-/backend roles
> - performance-wise, according to my plain vanilla tests, it is on par with mod_ssl
>
> The decision to offer it downstream is of course then made by the distros, as usual with experimental modules. And if and how it is then used rests with the users. It is an offered alternative for people.
>
> What would be the benefit to the project?
> - we offer people an alternative. If they feel the memory safety that Rust offers is important to them, they can do it with Apache httpd for the TLS stack.
> - we could see how people react to this and adapt our TLS offering accordingly. It being experimental, we remain free to change it. Or remove it again.
>
> Organizational Things:
> - the development was done by myself
> - the work was sponsored by the ISRG (https://www.abetterinternet.org), the org behind Let's Encrypt, as part of they "memory safety" initiative (https://www.memorysafety.org)
>
>
> Feedback appreciated,

I lean towards adding it as an httpd subproject at this level:

https://svn.apache.org/viewvc/httpd/

This frees you from all the complexity around experimental bits of httpd compared to fully supported bits.

This means that practically, it can be packaged through channels like EPEL until it becomes stable, at which point the distros will pick it up.

It also insulates us against external dependencies like rust. Languages wax and wane, should a rust2 coming along, or another language called oxide that’s better, we’re not left with aging code in our codebase. This is a problem that APR solves for us for operating systems.

Regards,
Graham
Re: mod_tls as experimental module? [ In reply to ]
Add it in :-)

> On Nov 24, 2021, at 4:46 AM, stefan@eissing.org wrote:
>
> Coming back to this. Since there was no feedback on my post: are people
> just too occupied/opposed/not interested?
>
> Curious,
> Stefan
>
>> Am 18.11.2021 um 18:48 schrieb stefan@eissing.org:
>>
>> How would you feel about adding mod_tls (https://github.com/abetterinternet/mod_tls) as an experimental module to Apache httpd?
>>
>> For people who have not followed that development:
>> - it is a TLS 1.2/1.3 implementation based on rustls, https://github.com/rustls/rustls
>> - the C API is rustls-ffi, found at https://github.com/rustls/rustls-ffi
>> - it is itself written in C, linking all the Rust things from the rustls-ffi library
>> - it does not bring any Rust into our code base
>> - functionality wise, it is a clear subset of what mod_ssl offers via openssl
>> (e.g. no client certificates now and not as tweakable - at least for now)
>> - it can be co-loaded and co-used with mod_ssl on different ports or front-/backend roles
>> - performance-wise, according to my plain vanilla tests, it is on par with mod_ssl
>>
>> The decision to offer it downstream is of course then made by the distros, as usual with experimental modules. And if and how it is then used rests with the users. It is an offered alternative for people.
>>
>> What would be the benefit to the project?
>> - we offer people an alternative. If they feel the memory safety that Rust offers is important to them, they can do it with Apache httpd for the TLS stack.
>> - we could see how people react to this and adapt our TLS offering accordingly. It being experimental, we remain free to change it. Or remove it again.
>>
>> Organizational Things:
>> - the development was done by myself
>> - the work was sponsored by the ISRG (https://www.abetterinternet.org), the org behind Let's Encrypt, as part of they "memory safety" initiative (https://www.memorysafety.org)
>>
>>
>> Feedback appreciated,
>>
>> Stefan
>>
>> PS. On a more personal note:
>> The way this project turned out was a clean separation between C and Rust. The API offered by rustls-ffi is colored by Rust's immutability/borrowed memory concepts, but there is nothing Rust special the C code needs to do. It remains C code. It remains in our core competence.
>>
>> Working with the rustls people has been nice and productive. The only thing I can report is that they come from the client TLS side and specific server needs require some explaining. There are things we can offer to them here.
>>
>> There are a lot of political things going on right now around OpenSSL and I definitely want to stay out of that. Again, we can offer this without having to switch ourself. Even better, customers can use this without needing to switch completely, as it co-exists. I think that fits into the concepts our server is designed with.
>>
>> Thanks for your time.
>>
>
Re: mod_tls as experimental module? [ In reply to ]
> Am 24.11.2021 um 12:42 schrieb Graham Leggett <minfrin@sharp.fm>:
>
> On 18 Nov 2021, at 19:48, stefan@eissing.org wrote:
>
>> How would you feel about adding mod_tls (https://github.com/abetterinternet/mod_tls) as an experimental module to Apache httpd?
>
> Having more choice is excellent.
>
>> For people who have not followed that development:
>> - it is a TLS 1.2/1.3 implementation based on rustls, https://github.com/rustls/rustls
>> - the C API is rustls-ffi, found at https://github.com/rustls/rustls-ffi
>> - it is itself written in C, linking all the Rust things from the rustls-ffi library
>> - it does not bring any Rust into our code base
>> - functionality wise, it is a clear subset of what mod_ssl offers via openssl
>> (e.g. no client certificates now and not as tweakable - at least for now)
>
> Client certs is a must for me. I know that they’re political, but my clients in finance don’t care.

Understood. They might come in the future, if rustls exposes the necessary functionality. But mod_tls is not intended as a full replacement for everything mod_ssl offers. For example, rustls will never support FIPS (my understanding).

>> - it can be co-loaded and co-used with mod_ssl on different ports or front-/backend roles
>> - performance-wise, according to my plain vanilla tests, it is on par with mod_ssl
>>
>> The decision to offer it downstream is of course then made by the distros, as usual with experimental modules. And if and how it is then used rests with the users. It is an offered alternative for people.
>>
>> What would be the benefit to the project?
>> - we offer people an alternative. If they feel the memory safety that Rust offers is important to them, they can do it with Apache httpd for the TLS stack.
>> - we could see how people react to this and adapt our TLS offering accordingly. It being experimental, we remain free to change it. Or remove it again.
>>
>> Organizational Things:
>> - the development was done by myself
>> - the work was sponsored by the ISRG (https://www.abetterinternet.org), the org behind Let's Encrypt, as part of they "memory safety" initiative (https://www.memorysafety.org)
>>
>>
>> Feedback appreciated,
>
> I lean towards adding it as an httpd subproject at this level:
>
> https://svn.apache.org/viewvc/httpd/
>
> This frees you from all the complexity around experimental bits of httpd compared to fully supported bits.
>
> This means that practically, it can be packaged through channels like EPEL until it becomes stable, at which point the distros will pick it up.
>
> It also insulates us against external dependencies like rust. Languages wax and wane, should a rust2 coming along, or another language called oxide that’s better, we’re not left with aging code in our codebase. This is a problem that APR solves for us for operating systems.

In its development, the arrival of mod_tls has caused changes in our server core. Not in any way related to Rust itself. But we added the capability to have more than one SSL/TLS provider in our server. So people can use whatever fits best for the parts they need it.

Future improvements in this area would be done easiest, if mod_tls is a module in our source base next to mod_ssl. API dependencies are managed better if we release enhanced versions together. I see no benefit for anyone involved in making it a separate Apache httpd subproject. It has a home on github with all its infrastructure.

Kind Regards,
Stefan

>
> Regards,
> Graham
> —
Re: mod_tls as experimental module? [ In reply to ]
On Thu, Nov 25, 2021 at 3:42 AM stefan@eissing.org <stefan@eissing.org>
wrote:
>...

> In its development, the arrival of mod_tls has caused changes in our
> server core. Not in any way related to Rust itself. But we added the
> capability to have more than one SSL/TLS provider in our server. So people
> can use whatever fits best for the parts they need it.
>
> Future improvements in this area would be done easiest, if mod_tls is a
> module in our source base next to mod_ssl. API dependencies are managed
> better if we release enhanced versions together. I see no benefit for
> anyone involved in making it a separate Apache httpd subproject. It has a
> home on github with all its infrastructure.
>

+1 on including mod_tls (or mod_rustls) in our tree as experimental. That
is *precisely* why we have the experimental label. Historically, the
concept of "subproject" has been ... suboptimal, to put it nicely.

The changes to the core can/should be made regardless of adoption of this
module.

Cheers,
-g
Re: mod_tls as experimental module? [ In reply to ]
For me it is a +1,

I didn´t say anything because I am not knowledgeable enough.

Stefan, if noone answers it is not because of lack of interest but
probably because you are several steps ahead :)

El jue, 25 nov 2021 a las 11:26, Greg Stein (<gstein@gmail.com>) escribió:
>
> On Thu, Nov 25, 2021 at 3:42 AM stefan@eissing.org <stefan@eissing.org> wrote:
> >...
>>
>> In its development, the arrival of mod_tls has caused changes in our server core. Not in any way related to Rust itself. But we added the capability to have more than one SSL/TLS provider in our server. So people can use whatever fits best for the parts they need it.
>>
>> Future improvements in this area would be done easiest, if mod_tls is a module in our source base next to mod_ssl. API dependencies are managed better if we release enhanced versions together. I see no benefit for anyone involved in making it a separate Apache httpd subproject. It has a home on github with all its infrastructure.
>
>
> +1 on including mod_tls (or mod_rustls) in our tree as experimental. That is *precisely* why we have the experimental label. Historically, the concept of "subproject" has been ... suboptimal, to put it nicely.
>
> The changes to the core can/should be made regardless of adoption of this module.
>
> Cheers,
> -g
>


--
Daniel Ferradal
HTTPD Project
#httpd help at Libera.Chat
Re: mod_tls as experimental module? [ In reply to ]
Thanks everyone for giving feedback. I summarise this as an overall positive response.

I will start next week on bringing this over as an experimental module. Also make
the test cases run on one of our travis instances.

Additionally, we need to clarify with ASF and ISRG if this needs some sort of
paperwork. Since the ISRG repository uses the Apache license, in my naive world
view, this should be quite an informal process. But I do not really know.

It would be great, if there is any formality here, for someone else to drive
this. I have mixed roles here as the author, contractor for ISRG and httpd
pmc member. Joe: any advice?

Kind Regards,
Stefan

> Am 25.11.2021 um 19:43 schrieb Daniel Ferradal <dferradal@apache.org>:
>
> For me it is a +1,
>
> I didn´t say anything because I am not knowledgeable enough.
>
> Stefan, if noone answers it is not because of lack of interest but
> probably because you are several steps ahead :)
>
> El jue, 25 nov 2021 a las 11:26, Greg Stein (<gstein@gmail.com>) escribió:
>>
>> On Thu, Nov 25, 2021 at 3:42 AM stefan@eissing.org <stefan@eissing.org> wrote:
>>> ...
>>>
>>> In its development, the arrival of mod_tls has caused changes in our server core. Not in any way related to Rust itself. But we added the capability to have more than one SSL/TLS provider in our server. So people can use whatever fits best for the parts they need it.
>>>
>>> Future improvements in this area would be done easiest, if mod_tls is a module in our source base next to mod_ssl. API dependencies are managed better if we release enhanced versions together. I see no benefit for anyone involved in making it a separate Apache httpd subproject. It has a home on github with all its infrastructure.
>>
>>
>> +1 on including mod_tls (or mod_rustls) in our tree as experimental. That is *precisely* why we have the experimental label. Historically, the concept of "subproject" has been ... suboptimal, to put it nicely.
>>
>> The changes to the core can/should be made regardless of adoption of this module.
>>
>> Cheers,
>> -g
>>
>
>
> --
> Daniel Ferradal
> HTTPD Project
> #httpd help at Libera.Chat
Re: mod_tls as experimental module? [ In reply to ]
On Fri, Nov 26, 2021 at 3:49 AM stefan@eissing.org <stefan@eissing.org>
wrote:
>...

> Additionally, we need to clarify with ASF and ISRG if this needs some sort
> of
> paperwork. Since the ISRG repository uses the Apache license, in my naive
> world
> view, this should be quite an informal process. But I do not really know.
>

We have numerous copies of permissive-licensed code within our
repositories, and that is fine as long as no such code is "more restrictive
than the ALv2". Since the existing mod_tls is provided under ALv2, then no
additional paperwork should be required. We are merely using that code
under the license provided.

The real question is whether the files to be imported into our repository
have headers that specify copyright held by others. For that, we need to
get the copyright owners' approval to replace that with our standard header.
https://www.apache.org/legal/src-headers.html
(if we want to change them; we could simply copy from upstream, or change
if the locus of development is our repository)

There is likely some other page talking about permission to switch out the
copyright header, but I don't have that link handy.

Cheers,
-g
Re: mod_tls as experimental module? [ In reply to ]
> Am 27.11.2021 um 14:21 schrieb Greg Stein <gstein@gmail.com>:
>
> On Fri, Nov 26, 2021 at 3:49 AM stefan@eissing.org <stefan@eissing.org> wrote:
> >...
> Additionally, we need to clarify with ASF and ISRG if this needs some sort of
> paperwork. Since the ISRG repository uses the Apache license, in my naive world
> view, this should be quite an informal process. But I do not really know.
>
> We have numerous copies of permissive-licensed code within our repositories, and that is fine as long as no such code is "more restrictive than the ALv2". Since the existing mod_tls is provided under ALv2, then no additional paperwork should be required. We are merely using that code under the license provided.
>
> The real question is whether the files to be imported into our repository have headers that specify copyright held by others. For that, we need to get the copyright owners' approval to replace that with our standard header.
> https://www.apache.org/legal/src-headers.html
> (if we want to change them; we could simply copy from upstream, or change if the locus of development is our repository)

Thanks Greg. I will talk to the ISRG about the header change.

Cheers, Stefan

>
> There is likely some other page talking about permission to switch out the copyright header, but I don't have that link handy.
>
> Cheers,
> -g
>