Thanks so much for holding them to account! This is great news. :)
On Sun, Jun 20, 2021 at 10:49 Jarek Potiuk wrote:
> Hello Everyone,
>
> GitHub Security Update: You can now specify finer-grained permissions
> for Github Tokens - something that I complained about to GitHub. This
> could help in
Hello Everyone,
GitHub Security Update: You can now specify finer-grained permissions
for Github Tokens - something that I complained about to GitHub. This
could help in preventing sophisticated supply-chain attacks like the
recent codecov attack
(https://www.computerweekly.com/news/252499587/Code
Vladimir,
You did not convince me at all, that hand-crafted
approach is almost the same security as submodule.
I simply don't agree with that statement and I think it simply best
to agree that we disagree and saying it's less secure is completely
unfounded (again this is my opinion, with which yo
Jarek> I am proposing here is just the way
Jarek>how we've done that at Airflow
Jarek, sharing the experience is awesome. No kidding. I did review Airflow
actions, there are nice bits,
however, I believe I do not need those. The workflows of my projects are
way simpler.
However, you suggested mak
On Thu, Jan 7, 2021 at 7:29 PM Matt Sicker wrote:
> GitHub supports SVN to an extent, but it's more of an SVN view of a
> Git repo. Try it out:
>
> svn info https://github.com/apache/whimsy/
>
> Path: whimsy
> URL: https://github.com/apache/whimsy
> Relative URL: ^/
> Repository Root: https://git
GitHub supports SVN to an extent, but it's more of an SVN view of a
Git repo. Try it out:
svn info https://github.com/apache/whimsy/
Path: whimsy
URL: https://github.com/apache/whimsy
Relative URL: ^/
Repository Root: https://github.com/apache/whimsy
Repository UUID: 54ef964a-1539-08b0-68b0-ce57b
On Thu, Jan 7, 2021 at 6:56 PM Vladimir Sitnikov <
sitnikov.vladi...@gmail.com> wrote:
> What I mean is that there's a trivial workaround which does not require
> significant changes to the repository layout. On top of that, it does not
> change developer's workflows (they do not need to learn sub
What I mean is that there's a trivial workaround which does not require
significant changes to the repository layout. On top of that, it does not
change developer's workflows (they do not need to learn submodules)
On top of that, git submodules are NOT available for SVN repositories.
>GitHub supp
Very simple. Submodule are a standard git feature and provide automated
compliance with
https://docs.github.com/en/free-pro-team@latest/actions/learn-github-actions/security-hardening-for-github-actions#using-third-party-actions
* submodules allow you to perform code review before the merge. You g
Jarek>What we propose:
Jarek>.gitmodules
What is the purpose of git submodules here?
However, that suggests there's a way easier workaround (see PR
https://github.com/apache/calcite/pull/2318 ).
Action repository can be cloned right before the action is used.
No submodules needed, and the workarou
>
>
>
> I am aware of how to use Docker in our build jobs... I am talking about
> Docker based GitHub Actions. They can have published docker
> images that they used so they do not get rebuilt all of the time. I called
> out SuperLinter as just an example.
>
Same thing. You can build and push D
On Wed, Jan 6, 2021, 8:39 AM Jarek Potiuk wrote:
> >
> >
> >
> > Btw this is really not ideal if the action is docker based like the
> GitHub
> > SuperLinter. Rebuilding this takes forever if it does not pull the
> > existing container.
> >
>
> I belive super linter is an official GitHub one. Al
>
>
>
> If we ban persisted credentials in the checkout action it becomes very hard
> to commit the static website build. My example is what triggered this
> whole conversation about how they are persisted because this is how it
> works for us today, which I guess was not common knowledge.
>
This
>
>
>
> Btw this is really not ideal if the action is docker based like the GitHub
> SuperLinter. Rebuilding this takes forever if it does not pull the
> existing container.
>
I belive super linter is an official GitHub one. All official actions that
are
GitHub owned are 'business as usual'. And
On Wed, Jan 6, 2021, 8:13 AM Matt Sicker wrote:
> Website builds are handled by a specific deployment script that
> doesn't necessarily need to give write access to GitHub Actions or
> other builds. Unless you're talking about generating a static site and
> committing it to git and then having it
Website builds are handled by a specific deployment script that
doesn't necessarily need to give write access to GitHub Actions or
other builds. Unless you're talking about generating a static site and
committing it to git and then having it published? Which is also
somewhat supported for website b
On Wed, Jan 6, 2021, 7:31 AM Jarek Potiuk wrote:
> I prefer constructive approach rather than criticising and complaining, and
> I think we found (together with Ash) even better approach with submodules.
>
> Daniel - I know you will be working on the infra side on that - I think you
> should
> co
I prefer constructive approach rather than criticising and complaining, and
I think we found (together with Ash) even better approach with submodules.
Daniel - I know you will be working on the infra side on that - I think you
should
consider making the below submodule approach the "highly recomme
Jarek>Actions are usually rather small
https://github.com/burrunan/gradle-cache-action becomes 3 megabytes of
JavaScript when compiled.
It takes a couple of minutes to build the action itself.
Jarek>but judging from some recent discussions
Jarek>this is very clear from legal point of view they on
>
>
> Please, no. The inclusion of the third-party code into the project
> repository has non-trivial licensing implications.
>
I do not think (but correct me if I am wrong) that this is the case.
I think once the licence is OK, it has very little implications. The
implications
are mostly when yo
Jarek>so maybe that can lead to a recommendation from the INFRA.
Please, no. The inclusion of the third-party code into the project
repository has non-trivial licensing implications.
GitHub Action should be treated not that different from any other project
dependency.
If infra team forbids action
Hello everyone,
Coming back to the thread. Apache Beam project solved the problem in a slightly
different way than we did in Airflow, and I think it might be a bit better, so
maybe that can lead to a recommendation from the INFRA.
https://github.com/apache/beam/pull/13670
Rather than cloning t
Hi Matt,
You are still also correct:-
https://jenkins-ccos.apache.org/job/websites1/
https://jenkins-ccos.apache.org/job/websites2/
both are floating agents available for all client masters.
HTH
On Mon, Jan 4, 2021 at 8:45 PM Matt Sicker wrote:
> Seems as though my information on that websit
Seems as though my information on that websites node is out of date.
That's no longer a node and is handled separately:
https://cwiki.apache.org/confluence/display/INFRA/git+-+.asf.yaml+features#git.asf.yamlfeatures-WebSiteDeploymentServiceforGitRepositories
If I recall correctly, I believe some i
Thanks for explaining the Jenkins security model.
Matt> which can write to ASF infrastructure that I know of are all in the
Matt> websites node which have scripts and such explicitly to secure its use
Matt> case (mostly via the .asf.yaml config options for your site branch).
I am afraid I do not
Couple things about Jenkins credentials:
1. The credentials are stored encrypted in the controller and are
dynamically decrypted and bound to jobs over the Jenkins remoting
protocol. A malicious dependency would not be able to gain access to
other credentials in Jenkins unless you're running your
FYI. I've filed two issues to GH via https://bounty.github.com/ - let's see
what their security teams do with those.
BTW. Brennan, if there is any reward, happy to share it with you :)
J.
On Wed, Dec 30, 2020 at 4:03 PM Jarek Potiuk
wrote:
> Got some feedback from GH support . It's both good
Got some feedback from GH support . It's both good and bad.
1) Indeed GITHUB_TOKEN is not available for actions that do not explicitly
get it passed to them
2) But it's much worse - the actions themselves can have (and even add) new
inputs and get the GITHUB_TOKEN set as default value via:
defa
FYI We looked at the source code of the checkout action and indeed it seems
it uses some kind of token, possibly GITHUB_TOKEN by simply using this:
https://github.com/actions/checkout/blob/main/src/input-helper.ts#L108
// Auth token
result.authToken = core.getInput('token', {required: true})
Jarek>What credentials are you talking about?
Please report it to security@ then. If it works this way, this is serious
security threat IMHO.
On Wed, Dec 30, 2020 at 11:42 AM Vladimir Sitnikov <
sitnikov.vladi...@gmail.com> wrote:
> Jarek>What credentials are you talking about?
>
> For instance
Jarek>What credentials are you talking about?
For instance, asfNexusUsername/asfNexusPassword (see
https://cwiki.apache.org/confluence/display/INFRA/Gradle+Installations )
I assume there exists something like git-websites Jenkins node label that
has privileges to update project site (
https://cwik
I also sent incident report to secur...@apache.org for the checkout action.
If it is confirmed that it works this way, this is a really serious issue
IMHO.
On Wed, Dec 30, 2020 at 11:24 AM Jarek Potiuk wrote:
>
> Jarek>Installing and even running commands via PIP does not expose
>> GITHUB_TOKEN
> Jarek>Installing and even running commands via PIP does not expose
> GITHUB_TOKEN
> (and this is the real threat). It at most exposes the local build
>
> Running PIP at the ASF Jenkins instance (e.g. https://ci-beam.apache.org/
> )
> exposes ASF credentials to a malicious PIP package.
> Does that
Jarek>One comment about PIP/NPM packages - it's a very different level of
threat
Jarek>IMHO.
It is different, however, it is way more serious.
That is why it is wrong to make such a disruption for GitHub Actions while
we keep
the door open for NPM/PIP/Maven/Ant/... issues.
Jarek>Installing and e
I think this is a huge security problem a
I've opened a High Priority security ticket to Github
https://support.github.com/ticket/personal/0/964498 (it's personal so you
won't see it).
I am also immediately setting the "persist-credentials: false" to all our
checkout actions. This is really, bad i
On Wed, Dec 30, 2020, 1:25 AM Jarek Potiuk wrote:
> >
> >
> > This is only sorry of correct. If you are using the standard checkout
> > action and install a package from pypi/npm at a later step that package
> > absolutely can push to the Apache repo when it runs in a push context (pr
> > context
>
>
> This is only sorry of correct. If you are using the standard checkout
> action and install a package from pypi/npm at a later step that package
> absolutely can push to the Apache repo when it runs in a push context (pr
> context it is read-only). This later step does not need the token passe
On Wed, Dec 30, 2020, 12:45 AM Jarek Potiuk
wrote:
> One comment about PIP/NPM packages - it's a very different level of threat
> IMHO.
>
> Installing and even running commands via PIP does not expose GITHUB_TOKEN
> (and this is the real threat). It at most exposes the local build
> environment t
One comment about PIP/NPM packages - it's a very different level of threat
IMHO.
Installing and even running commands via PIP does not expose GITHUB_TOKEN
(and this is the real threat). It at most exposes the local build
environment to be hacked for the time of build but as long you are using
Gith
Just picking out one point below.
On Wed, Dec 30, 2020 at 12:47 PM Greg Stein wrote:
> On Tue, Dec 29, 2020 at 8:08 PM Brennan Ashton
> wrote:
> [...]
> TBH I don't see how the threat surface here is that much different
> > than pulling down
> > packages from pypi to npm at build time.
> >
> An
On Tue, Dec 29, 2020 at 8:08 PM Brennan Ashton
wrote:
> On Tue, Dec 29, 2020 at 5:33 PM Greg Stein wrote:
> > One of things that we will likely do is perform a scan of any
> > Action/workflow .yml at commit time, to ensure that any "uses:" is
> defined
> > with a hash rather than a tag. That sho
On Tue, Dec 29, 2020 at 5:33 PM Greg Stein wrote:
>
> One of things that we will likely do is perform a scan of any
> Action/workflow .yml at commit time, to ensure that any "uses:" is defined
> with a hash rather than a tag. That should prevent the kind of attack Jarek
> described where Action FO
On Tue, Dec 29, 2020 at 2:30 PM Jarek Potiuk
wrote:
>...
> On Tue, Dec 29, 2020 at 2:12 PM Vladimir Sitnikov <
> sitnikov.vladi...@gmail.com> wrote:
>
>...
> Jarek>This is exactly what Greg is writing about
> >
> > Greg's message was very vague, so I asked for clarification.
>
> I hope my explan
Not speaking for INFRA (I am but a humble user of INFRA services) but my
comments below.
On Tue, Dec 29, 2020 at 2:12 PM Vladimir Sitnikov <
sitnikov.vladi...@gmail.com> wrote:
> Jarek>Github Action can use the GITHUB_TOKEN to perform write operations to
> anything in the repo
>
> Once again: GIT
Jarek>Github Action can use the GITHUB_TOKEN to perform write operations to
anything in the repo
Once again: GITHUB_TOKEN has to be explicitly used in the YAML file.
If GITHUB_TOKEN is not mentioned in the YAML, then write access is NOT
possible.
Jarek>This is exactly what Greg is writing about
Hello Vladimir, all,
Happy to share our experiences and thoughts. Better late than never - but
we discussed that in the apache-airflow private group before and we've
implemented a number of protections in place so happy
to share our learnings and practices.
> Gregg,
> Do you have pointers that cl
Greg>Using an action defined by a third party, which might modify Apache
Greg>repositories in unknown ways ... not something we want.
Gregg,
Do you have pointers that clarify how actions can modify Apache
repositories?
I strongly believe that Actions are read-only by default.
AFAIK the only way G
On Sun, Dec 27, 2020 at 11:29 AM Jarek Potiuk
wrote:
> For the records - I also looked up the discussion we had about the
> Github Action issues
>
> That was a discussion on 7th of October on priv...@airflow.apache.org
> (for those who have access there - here is the link:
> https://lists.apache.
> On Dec 27, 2020, at 7:53 AM, kezhenxu94@apache wrote:
> We (SkyWalking community) are also building some useful tools that may
> benefit more ASF projects, such as a license audit tool
> (http://github.com/apache/skywalking-eyes) that I believe most projects will
> need it
In case
For the records - I also looked up the discussion we had about the
Github Action issues
That was a discussion on 7th of October on priv...@airflow.apache.org (for
those who have access there - here is the link:
https://lists.apache.org/thread.html/re92b77f64e5923ec0044edf3a060339b9e170f9438e2fde08
| While pinning to a commit is a good workaround, it doesn’t substitute for
a security review.
Absolutely. And we do review the particular commit we want to switch to. We
do it since this commit as of October 7th in Apache Airflow when we
discussed and realized the threat:
https://github.com/apach
Hi Jarek, we (Apache SkyWalking project) are using one of them
(https://github.com/apache/airflow-cancel-workflow-runs). The tools listed here
are very helpful, they save the resources by cancelling duplicated builds.
> I do not want to take any responsibility for it for other projects to use it
Manually reviewing third party actions would be comparable to reviewing
shared libraries in Jenkins or Maven plugins or similar. Since the code
runs in a privileged context, allowing arbitrary git repositories to take
part would allow for supply chain attacks. While pinning to a commit is a
good wo
I have now clones of the actions we've been using in Airflow but I know few
other projects are using it.
I think I should NOT encourage others to use it. Not at all. If you want to
use them you should create your own clones.
The skywalking project switched to those but I am going to ask them to ma
Sure. I perfectly understand, no problem and no hard feelings. I am not at
all against such immediate actions, just to message
I perfectly understand why it happened and I'd probably do the same.
But I would try to at least warn everyone involved immediately after,
explaining it was a necessity).
We are all human, and fallible. Could we have resolved this earlier, and
rolled it out in a controlled manner? Yes. But we did not understand the
issue, and (thus) did not apply the restriction sooner.
Volunteers help out Infra with alerts on JDK releases, about email issues,
etc ... We would cert
Ok. Thanks. I understand now.
But it would be great if you would explain the context in the announcement
and try to be a bit more vocal (builds@ seems like a great place to
announce such changes).
It caught everyone by surprise.
Again - the scenarios you explain were already discussed before (I
On Sun, Dec 27, 2020 at 6:54 AM Jarek Potiuk
wrote:
>...
> Was it as a response to some security incident that would justify such
> immediate and disruptive action without an earlier warning? What was the
> reasoning behind this?
>
Yes.
"badly executed" occurs when we believe there is a *security* issue.
Using an action defined by a third party, which might modify Apache
repositories in unknown ways ... not something we want.
Or when a PMC determines that third party Action is safe, in April, but
then gets compromised in August
Question:
Do you think it was a good idea, to restrict it on Sunday right after Xmas
literally two minutes after it has been announced on users@, where really
builds@ is the list we are mostly discussing stuff related to builds?
I am sure you do realize that this way you force all the project
mai
Ok. IT works after logging. I will make another comments shortly after
subscribing to the list but I think this was very badly executed.
J.
On Sun, Dec 27, 2020 at 1:38 PM Jarek Potiuk wrote:
> the link does not work
>
> On Sun, Dec 27, 2020 at 1:34 PM Roy Lenferink
> wrote:
>
>> This is rel
the link does not work
On Sun, Dec 27, 2020 at 1:34 PM Roy Lenferink wrote:
> This is related to the thread Daniel just posted on the users@infra list:
>
> https://lists.apache.org/thread.html/r900f8f9a874006ed8121bdc901a0d1acccbb340882c1f94dad61a5e9%40%3Cusers.infra.apache.org%3E
>
> Op zo 27 d
This is related to the thread Daniel just posted on the users@infra list:
https://lists.apache.org/thread.html/r900f8f9a874006ed8121bdc901a0d1acccbb340882c1f94dad61a5e9%40%3Cusers.infra.apache.org%3E
Op zo 27 dec. 2020 om 13:26 schreef Andreas Veithen <
andreas.veit...@gmail.com>:
> Same for http
Same for https://github.com/apache/axis-axis2-java-core (with no
configuration changes on our side).
Andreas
On Sun, Dec 27, 2020 at 12:25 PM Jarek Potiuk wrote:
> Is there a change in the policy of Apache Airflow to only allow
> actions hosted in-organization? Or is it a mistake in configurati
64 matches
Mail list logo
