email-ext no mor resolve template absolute path

[jer...@bodycad.com]

Hi,

is there a change into email-ext lately (I was into Jenkins 2.51 and email-ext 2.56, now updated to Jenkins 2.54 with 2.57.2)  that could prevent email-ext to fetch template into the node with an absolute path? My outgoing email used to work now I receive this into my email body:

Jelly file [c:/Jenkins/workspace/CAD_CPP/CAD_CPP_ContinuousBuild@tmp/email_template_file.jelly] was not found in $JENKINS_HOME/email-templates.

The file was present on the node is there a way to fix this or an approval switch to enable?

I'm guessing this got broke into the 2.57 or 2.57.2 release:

https://wiki.jenkins-ci.org/display/JENKINS/Email-ext+plugin

P.S.: Sometime I wish there was a non secure global switch and we could accept the server run into a secure local network and don't have to mess around with all the security non sense and modification that always broke the build machine at every Jenkins update. I still have the slave hang during the whole building phase, there's still many bugs report for this (over 2 years, and this important bug don't get fix, then we see 'security' features that remove working use case all the time). Maintaining Jenkins is more time consuming then maintaining our code base. Maybe I should stop update it, but I still hope the Windows slave hanging will be fix one day, if that day come around and I get it to work, I might highly tempted to stop updating.

[jer...@bodycad.com]

Anybody know if this is part of another security risk or just a bug of emailext command into pipeline?

I was creating a template on teh fly by concat of wanted sections by my pipeline steps results

def email_template_file = pwd([tmp: true]) + "\\email_template_file.jelly";

writeFile([file: email_template_file, text: email_info['body']]);

Sending the email was working before.

emailext body: '${JELLY_SCRIPT,template="' + email_template_file.replaceAll('[\\\\]','/') + '"}'

This used to work now it seem like email-ext doesn't check into the current node path, but only into the $JENKINS_HOME/email-templates!

Since I create the template by concat part, I was keeping it into the node tmp. This is particulary annoying since many node can try to do the same, so I will have to copy a file back on the master with a guid name and send the email then delete that file back.

Any help would be appreciate (or plugin fix too that can handle both absolute path again and the relative one for those who have a static template).

[jer...@bodycad.com]

I opened a ticket about it:

https://issues.jenkins-ci.org/browse/JENKINS-43903

[Slide]

This is probably due to the fact that reading a template from the workspace or absolute path is a security risk. 

On Thu, Apr 27, 2017 at 6:38 AM <jer...@bodycad.com> wrote:

I opened a ticket about it:

https://issues.jenkins-ci.org/browse/JENKINS-43903

--
You received this message because you are subscribed to the Google Groups "Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/5942c8d2-177b-4441-9c7f-86a6fe4a9d42%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[jer...@bodycad.com]

this security non sense is getting annoying, anyway I can workaround by writing the file on the master anyway. But since you can run almost anything into a python/perl/bash/batch... scripts, the security should be at the scripts trust not what it's content in the end, if you trust the source and ensure the script is a trusted user/server, no need to go at every details of the scripts operation. We should have a way to sign and trust Jenkinsfile script and be done with the security. Try to secure each and every call inside the script language when you can call sh or bat is a false security.

I don't known how to do it exactly right off the bat, but my guess it's make more sense. Preventing me from doing a file operation for security purpose into Groovy, but I can call sh todo it anyway doesn't give much except frustration. I totally fail to see why something like:

• new java.util.Date
  
• method java.util.Map containsKey java.lang.Object
  
• staticMethod org.codehaus.groovy.runtime.DefaultGroovyMethods leftShift java.util.Map java.util.Map
  
• staticMethod org.codehaus.groovy.runtime.DefaultGroovyMethods minus java.lang.String java.lang.Object
  
• staticMethod org.codehaus.groovy.runtime.DefaultGroovyMethods plus java.util.List java.lang.Iterable
  
• staticMethod org.codehaus.groovy.runtime.DefaultGroovyMethods plus java.util.List java.util.Collection
• staticMethod org.codehaus.groovy.runtime.DefaultGroovyMethods plus java.util.Map java.util.Map
• staticMethod org.codehaus.groovy.runtime.DefaultGroovyMethods println groovy.lang.Closure java.lang.Object

are security risk?!? seriously, I call bullshit. Just do yourself a favor and call whatever you want to do into sh or python and do it anyway. And even if it would want to check if the process do something illegal, we still could launch other process/pipe from those command and nothing could be really done or known. As long as the Jenkins user have limited privilege on the machine and you trust the Jenkinsfile (some kind of certificate maybe).

This false security is grabbing way too much ground over the features/usability ground and that's sad, the concept is good but start to feel like it's going down the rabbit hole.