-
Notifications
You must be signed in to change notification settings - Fork 30
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-40533] Allow definition of sandboxed libraries at global scope #129
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks right.
src/main/java/org/jenkinsci/plugins/workflow/libs/AbstractGlobalLibraries.java
Outdated
Show resolved
Hide resolved
src/main/resources/org/jenkinsci/plugins/workflow/libs/Messages.properties
Outdated
Show resolved
Hide resolved
return Jenkins.MANAGE; | ||
} | ||
|
||
@Extension(ordinal=0) public static class ForJob extends AbstractForJob { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this implementation needs to wrap the returned libraries in ResolvedLibraryConfiguration
like FolderLibraries.ForJob
to avoid introducing a new security issue like what was fixed by ace0de3.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe the trust flag is enough though, I am not sure. Either way I would look at old security fixes here carefully to see if anything extra needs to be done to separate the two global configurations in all contexts.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Indeed, this is addressed in 98322fb
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking at the old fix in more detail, I think it was probably fine as you had it originally because of this line:
pipeline-groovy-lib-plugin/src/main/java/org/jenkinsci/plugins/workflow/libs/LibraryAdder.java
Line 132 in b98828a
String source = kind.getClass().getName(); |
I think folder-based libraries just needed special treatment to distinguish between folders with the same name defined at different levels since they use the same LibraryResolver
class. Since the new untrusted global libraries use a distinct resolver class and only exist in a single place, things should be fine without wrapping LibraryConfiguration
s. Your changes use getClass().getName()
anyway so the behavior should be identical. I didn't try testing it though.
@dwnusbaum best to “request changes” if in doubt whether there might be a security issue. |
return getConfiguration() | ||
.getLibraries() | ||
.stream() | ||
.map(this::mayWrapLibrary) | ||
.collect(Collectors.toList()); | ||
} | ||
|
||
protected LibraryConfiguration mayWrapLibrary(LibraryConfiguration library) { | ||
return library; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking more carefully, it is probably unnecessary to wrap these, see #129 (comment).
src/main/java/org/jenkinsci/plugins/workflow/libs/AbstractGlobalLibraries.java
Outdated
Show resolved
Hide resolved
@dwnusbaum can you merge this ? |
This lets users with
Jenkins.MANAGE
permission define untrusted global libraries.They can be used in a similar way than folder libraries, except they are available globally.
Testing done
Submitter checklist