Tracking patches to copy-to-slave Jenkins plugin

Guilherme Salgado guilherme.salgado at linaro.org
Tue Jan 17 18:48:44 UTC 2012


Ooops, I meant to CC the infrastructure list instead of linaro-dev the 
email below.

On 17/01/12 15:44, Guilherme Salgado wrote:
> Hi Paul,
>
> On 17/01/12 12:31, Paul Sokolovsky wrote:
>> Hello Guilherme,
>>
>> Here's the matter about "WI" we have from the team meeting. I posted
>> about that matter previously but here's quick recap: we wanted to
>> start using the copy-to-slave on android-build, and I found that it has
>> security hole, essentially it allows a user w/o admin permissions to
>> get access to admin info, which can be as serious as to allow to steal
>> EC2 machine time.
>>
>> What I did is notified the plugin maintainer, and also quickly whipped
>> a "short-circuit" type workaround - I just removed the offending option
>> altogether. In maintainer's place, I wouldn't accept that patch as is -
>> obviously, is some configurations there's no real security risk with
>> that option, and some people have it in use. Proper solution would take
>> adding UI configuration page, but I don't know Jenkisn well enough to
>> do that (and before going for that, there're 2-3 Jenkins hacking
>> related tasks waiting in queue for months). Last step in this so far is
>> that maintainer did some changes (again, I doubt they're based on my
>> patch much) and asked for review, in my TODO.
>>
>> We didn't really exchange email, all communication is as the comments
>> to the plugin page:
>>
>> https://wiki.jenkins-ci.org/display/JENKINS/Copy+To+Slave+Plugin?focusedCommentId=59509028#comment-59509028
>>
>>
>> There's also a bug: https://issues.jenkins-ci.org/browse/JENKINS-12281
>>
>> My changes are in the form of fork repo:
>> https://github.com/pfalcon/copy-to-slave-plugin
>>
>>
>> So, based on all this, I wouldn't think there's something to
>> patch-track: it's not that much of upstream contribution, more of
>> upstream bugreport + local workaround. But if you think we could track
>> anything out of this, I'd appreciate a hint how to start with that.
>
> Right, it probably doesn't make sense to teach patches.l.o how to suck
> patches submitted by Linaro engineers from issues.jenkins-ci.org as we
> don't expect to see many contributions from Linaro there. If that
> changes in the future, we can certainly work something out, like we did
> for gerrit.
>
> The way you described it sounds like the patch you submitted isn't even
> going to be merged upstream, but if you have others that you expect to
> be, you can just email a copy of them to patches at l.o, as described at
>
> https://wiki.linaro.org/Process/UpstreamPatches
>
> In that case you'll also want to ask for the creation of a new project
> on patches.l.o (instructions also on the page above)
>


-- 
Guilherme Salgado <https://launchpad.net/~salgado>



More information about the linaro-dev mailing list