Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
Re: Discussions on Security Enhancements
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Diogo Sant'Anna via curl-library <curl-library_at_lists.haxx.se>
Date: Thu, 10 Nov 2022 13:05:03 -0300
>
> I think your last response didn't reach the curl-library list as you
> weren't
> subscribed yet.
>
Ups sorry, I had not realized that. Thanks for getting me subscribed!
I want to be clear and say that I'm not dissing the tool nor the idea, I
> just
> don't think it is very helpful *to us*.
No worries! That was what I thought as well. Thanks for the clarification,
though.
> We never click the merge button in the GitHub UI, we always merge
> pull-requests "manually" using git. This allows us to make sure the commit
> messages are exactly the way we want them and is a much easier/faster way
> to
> squash/cleanup commits etc before merge.
>
> We only fairly infrequently add a "Reviewed-by:" line in the commit
> message,
> most commits are actually done without recording any review details. Most
> (but
> far from all) commits are still reviewed by someone else than its author.
> I
> think primarily my commits are at times not reviewed by anyone else.
>
Understood, thanks for the clarification.
> I now understand that you point out that the github workflows as they are
> setup right now for curl allow the jobs to write contents back into the
> git
> repo as hosted on github?
>
> If so, then we really need to stop that. It was however not immediately
> clear
> to me exactly what we want the permissions to be set to. Is 'read-all' too
> restrictive ?
>
I'll join my replies on this subject at the end of the email.
> >> 3 - "Dependency-Update-Tool High"
> >>
> > Could you tell which dependency-update-tool the project is currently
> using?
> > I can raise an issue to ask for its support.
>
> We don't have depdencies like that so there is no such tool. You build
> curl to
> use the dependencies that are installed in the machine where curl is
> built/run. We cannot scan for those on GitHub.
>
Acknowledged.
> Is read-all what we want?
>
> BTW, in the settings/actions section for the curl/curl repo under the
> "Workflow persmissions" title I have selected "Read respository contents
> persmission" which is described as: "Workflows have read permissions in
> the
> repository for the contents scope only."
>
> As opposed to the other alternative which says "Workflows have read and
> write
> permissions in the repository for all scopes"
>
> *read permissions* vs *read and write permissions*. If that doesn't
> restrict
> the workflows from writing content, then what does this option mean?
>
>
So, also answering your question back on the text, considering you have
selected "Read repository contents permission" at the github permissions,
your workflows are already secured against writing content. To have write
permissions, your workflows would need to explicitly declare those
privileges. You can read a comparison between the *read permissions* vs
*read and write permissions* here
<https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token>
.
Please note that a repo's default permission is not public, so I could not
know which one you had, and that's why I was warning you about the dangers
=)
Although with this current configuration already secures your repo from
workflows to write content, I'll list here some advantages on having them
also written on the workflows, and I'd be happy to write those changes if
you want, but I agree they're less relevant so that's totally up to you:
- The GitHub settings are not inherited by forks, so your repo is secure,
but your forks might not be.
- If by any reason this setting is changed, all your workflows might become
unprotected. And this is surprisingly common, as the github permissions
system is quite difficult to understand.
- Having the permissions written on the workflows follow the config-on-code
principle, bringing more transparency and making possible a tracking of the
settings. If any privilege must be changed, it would need to have a commit
and ideally a code review, which would make this change more explicit.
Sincerely,
Date: Thu, 10 Nov 2022 13:05:03 -0300
>
> I think your last response didn't reach the curl-library list as you
> weren't
> subscribed yet.
>
Ups sorry, I had not realized that. Thanks for getting me subscribed!
I want to be clear and say that I'm not dissing the tool nor the idea, I
> just
> don't think it is very helpful *to us*.
No worries! That was what I thought as well. Thanks for the clarification,
though.
> We never click the merge button in the GitHub UI, we always merge
> pull-requests "manually" using git. This allows us to make sure the commit
> messages are exactly the way we want them and is a much easier/faster way
> to
> squash/cleanup commits etc before merge.
>
> We only fairly infrequently add a "Reviewed-by:" line in the commit
> message,
> most commits are actually done without recording any review details. Most
> (but
> far from all) commits are still reviewed by someone else than its author.
> I
> think primarily my commits are at times not reviewed by anyone else.
>
Understood, thanks for the clarification.
> I now understand that you point out that the github workflows as they are
> setup right now for curl allow the jobs to write contents back into the
> git
> repo as hosted on github?
>
> If so, then we really need to stop that. It was however not immediately
> clear
> to me exactly what we want the permissions to be set to. Is 'read-all' too
> restrictive ?
>
I'll join my replies on this subject at the end of the email.
> >> 3 - "Dependency-Update-Tool High"
> >>
> > Could you tell which dependency-update-tool the project is currently
> using?
> > I can raise an issue to ask for its support.
>
> We don't have depdencies like that so there is no such tool. You build
> curl to
> use the dependencies that are installed in the machine where curl is
> built/run. We cannot scan for those on GitHub.
>
Acknowledged.
> Is read-all what we want?
>
> BTW, in the settings/actions section for the curl/curl repo under the
> "Workflow persmissions" title I have selected "Read respository contents
> persmission" which is described as: "Workflows have read permissions in
> the
> repository for the contents scope only."
>
> As opposed to the other alternative which says "Workflows have read and
> write
> permissions in the repository for all scopes"
>
> *read permissions* vs *read and write permissions*. If that doesn't
> restrict
> the workflows from writing content, then what does this option mean?
>
>
So, also answering your question back on the text, considering you have
selected "Read repository contents permission" at the github permissions,
your workflows are already secured against writing content. To have write
permissions, your workflows would need to explicitly declare those
privileges. You can read a comparison between the *read permissions* vs
*read and write permissions* here
<https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token>
.
Please note that a repo's default permission is not public, so I could not
know which one you had, and that's why I was warning you about the dangers
=)
Although with this current configuration already secures your repo from
workflows to write content, I'll list here some advantages on having them
also written on the workflows, and I'd be happy to write those changes if
you want, but I agree they're less relevant so that's totally up to you:
- The GitHub settings are not inherited by forks, so your repo is secure,
but your forks might not be.
- If by any reason this setting is changed, all your workflows might become
unprotected. And this is surprisingly common, as the github permissions
system is quite difficult to understand.
- Having the permissions written on the workflows follow the config-on-code
principle, bringing more transparency and making possible a tracking of the
settings. If any privilege must be changed, it would need to have a commit
and ideally a code review, which would make this change more explicit.
Sincerely,
-- • *Diogo Teles Sant Anna (he/him)* • Software Engineer (SWE) | SAO-OSC • Google Open Source Security Team (GOSST) • diogoteles_at_google.com <malcarria_at_google.com> | +55 (19) 98215-8522 <+55%2011%2093263-2263>
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2022-11-10