Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[JENKINS-63668] fix: auto re-request approval once dismissed #546

Draft
wants to merge 7 commits into
base: master
Choose a base branch
from

Conversation

meiswjn
Copy link

@meiswjn meiswjn commented Nov 27, 2023

This PR resolves JENKINS-63668. If a job fails because a script is not approved, it automatically re-requests the approval.
It also deprecates the current #using method and adds a new flag ignoreAdmin to it. This is due to concerns that administrators could unknowingly approve a script for everyone by running the job.

Should unblock #300 (hopefully - motivation behind this PR).

Testing done

  • Added automated test.
  • Followed previous reproduction steps from issue.

Submitter checklist

Edit tasklist title
Beta Give feedback Tasklist Submitter checklist, more options

Delete tasklist

Delete tasklist block?
Are you sure? All relationships in this tasklist will be removed.
  1. Make sure you are opening from a topic/feature/bugfix branch (right side) and not your main branch!
    Options
  2. Ensure that the pull request title represents the desired changelog entry
    Options
  3. Please describe what you did
    Options
  4. Link to relevant issues in GitHub or Jira
    Options
  5. Link to relevant pull requests, esp. upstream and downstream changes
    Options
  6. Ensure you have provided tests - that demonstrates feature works or fixes the issue
    Options

@meiswjn meiswjn force-pushed the fix/JENKINS-63668 branch 3 times, most recently from ae1520e to 3a8f7ee Compare November 27, 2023 12:31
@meiswjn
Copy link
Author

meiswjn commented Nov 27, 2023

@Wadeck, you wrote in #300:

I will not modify this method as it could have some impacts I am not aware of (like having script being auto-approved or related stuff)

@Wadeck I addressed your concern in 3a8f7ee. This should prevent any accidential auto-approvals by admins unknowingly running a script and approving it for everyone.

@Wadeck
Copy link
Contributor

Wadeck commented Nov 27, 2023

Great, thanks @meiswjn for the bug fix. I will not have the time to test it but I believe the maintainers of the plugin will be happy to move forward this PR and the previous one about the UI revamp :)

@Wadeck Wadeck changed the title fix: auto re-request approval once dismissed [JENKINS-63668] [JENKINS-63668] fix: auto re-request approval once dismissed [JENKINS-63668] Nov 27, 2023
@Wadeck Wadeck changed the title [JENKINS-63668] fix: auto re-request approval once dismissed [JENKINS-63668] [JENKINS-63668] fix: auto re-request approval once dismissed Nov 27, 2023
@meiswjn meiswjn marked this pull request as ready for review November 27, 2023 14:43
@meiswjn meiswjn requested a review from a team as a code owner November 27, 2023 14:43
@jglick jglick added the bug label Nov 27, 2023
@meiswjn
Copy link
Author

meiswjn commented Dec 12, 2023

Hey @daniel-beck,
Did you have any time to look at this PR already?

Thanks!
Jan

@meiswjn
Copy link
Author

meiswjn commented Jan 9, 2024

Hey @daniel-beck, perhaps you have missed this. If you do not have time, perhaps @Wadeck has time?

@Wadeck
Copy link
Contributor

Wadeck commented Jan 9, 2024

👋 Hello Jan, currently we (Daniel and me) are both lacking time however I pinged the maintainers of this plugin to see if they have some time for this PR :)

@jglick
Copy link
Member

jglick commented Jan 9, 2024

Everything related to ScriptApproval should be considered basically deprecated (do not use this system), and adjusting the UX is certainly dangerous. If @daniel-beck or @Wadeck wants to review this and take responsibility for the behavior, go ahead (and ideally get added to the maintainer list).

@rsandell
Copy link
Member

There are still plenty of usage of ScriptApproval outside of pipeline and where sandboxing isn't really possible. Email-ext templates for example is the first that comes to mind.

final ConversionCheckResult result = checkAndConvertApprovedScript(script, language);
if (!result.approved) {
if (!Jenkins.get().isUseSecurity() ||
if (!Jenkins.get().isUseSecurity() ||
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The boolean logic here has become too complex and unreadable, so it is very difficult to grok if the added logic is sound.

But why do you need the new parameter at all? From the description it seems like it should suffice to just set approveIfAdmin to false?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey @rsandell, thanks for the review!

I agree that it is too complex.
The reason for adding this can be found here.

Does this answer your question? If yes, I would improve the readbility of the boolean. If not, let's further discuss its need.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry I couldn't find @Wadeck 's comment so I am still a bit lost as to why, though I trust that there is a legitimate reeason for it I just would like to understand that reason 😅

If you could clean up the logic to make it more readable that would be hugely helpful :) Maybe it is just enough to reformat the code?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No worries!
#300 (comment)
There you go :) Last sentence in that comment.

What ignoreAdmin does can be seen here. When the using() function is called from a job, it will not cause scripts to be approved automatically. If the admin did set up the script, it would have already been approved on saving the configuration.

It is supposed to prevent the scenario, where an admin starts a job, not knowing that it will approve a potentially dangerous script in it.

I am reformatting it in a sec

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

though I trust that there is a legitimate reeason for it I just would like to understand that reason 😅

Yes, please! I am new to this repository's source code. There is a chance that I am completely wrong with that new boolean and since this is security relevant, I totally support that you question it.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tried to make it much more readable, even though not as "fancy" as before. Does this help? @rsandell

@rsandell
Copy link
Member

Just as an FYI I remember explicitly doing this in email-ext at least for when a template is picked up from the workspace; it will call configuring followed by using every time, which might be annoying for some admins 😅

@meiswjn
Copy link
Author

meiswjn commented Jan 12, 2024

Just as an FYI I remember explicitly doing this in email-ext at least for when a template is picked up from the workspace; it will call configuring followed by using every time, which might be annoying for some admins 😅

What would be the outcome of this scenario? I think once the script is approved, the admin does not have to do anything unless approval is revoked :)

@jglick
Copy link
Member

jglick commented Jan 16, 2024

outside of pipeline and where sandboxing isn't really possible. Email-ext templates for example

Getting off topic, but FWIW many cases would be better handled by replacing that plugin with e.g.

mail subject: 'Failure', …, body: """
Build broke! $BUILD_URL
"""

@meiswjn meiswjn requested a review from rsandell January 22, 2024 08:16
@meiswjn
Copy link
Author

meiswjn commented Feb 6, 2024

Hello @rsandell,
Given that this PR is open for several months now, would you be able to provide a timeline or delegate the review?

Thanks! I appreciate your work!

@rsandell
Copy link
Member

rsandell commented Feb 6, 2024

I am very sorry for the delay, our team is quite swamped at the moment and this keeps falling between the cracks. So thanks for the reminder!
I've set a reminder so that me or someone in my team doesn't forget about it again. So when there is a calm hour we'll take a look again.

@meiswjn
Copy link
Author

meiswjn commented Apr 3, 2024

I am very sorry for the delay, our team is quite swamped at the moment and this keeps falling between the cracks. So thanks for the reminder! I've set a reminder so that me or someone in my team doesn't forget about it again. So when there is a calm hour we'll take a look again.

Thanks, @rsandell! Would you have an ETA for me?

@meiswjn
Copy link
Author

meiswjn commented May 16, 2024

In the current state, this PR is not compatible with some of the recent implemented changes. Moving it to draft until I find some time.

@meiswjn meiswjn marked this pull request as draft May 16, 2024 07:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
4 participants