Community
Participate
Working Groups
in the platform repo the launcher executables for windows are not signed. This is causing problems with windows defender. Need to publish signed executables for windows in platform repo.
We use winsigner plugin(https://www.eclipse.org/cbi/sitedocs/eclipse-winsigner-plugin/sign-mojo.html) to sign windows executables this is done as part of building Platform, sdk and equinox products. Here is pom.xml for SDK producthttps://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/tree/eclipse.platform.releng.tychoeclipsebuilder/sdk/pom.xml In this case we have tied winsigner plugin to package phase. The problem is there are multiple goals tied to package phase like tycho-p2-repository:assemble-repository tycho-p2-repository:archive-repository tycho-p2-director:materialize-products tycho-p2-director:archive-products we need to run eclipse-winsigner-plugin:sign before tycho-p2-repository:archive-repository. currently it is running before tycho-p2-director:archive-products Need to rationalize maven phase selection with these goals. @mat Can you please help in this?
This not required for now. Closing.
But it's something that should be done for Eclipse 4.13 and for SimRel 2019-09, so I'm not sure how it makes sense to close this?
(In reply to Ed Merks from comment #3) > But it's something that should be done for Eclipse 4.13 What is the problem exactly, I mean the visible problem and not just "it's not signed"? Are you sure it doesn't break clients that rebrand and sign again? Do we sign it for the other platforms? I suggest someone who has a concrete issue reports that bug and we can then use that bug or reopen this one. I'd prefer the latter.
The visible problem is that it's not signed. That's visible to any user running this executable. You only have look at the properties of the file to see (visibly) that there is no digital signature. So I must ask, why do we bother sign the *.exe that's in the zip file is it's not a problem for it not to be signed? In the end, *I* have a concrete issue with this. The installer (and p2 director) does not (and cannot) produce an installation with signed executables. I.e., it doesn't produce something that's equivalent to the distributed zipped packages. I'm not comfortable that and I'm a user too, so it seems odd that I am not permitted to report it as a problem. So I don't get this attitude at all. Resolving this as invalid when that flies in the fact of the reality seems totally inappropriate to me. This may well require downstream changes in the build processes, but now is the time to make sure that all works properly. Please don't return this as invalid.
(In reply to Ed Merks from comment #5) > The visible problem is that it's not signed. That's visible to any user > running this executable. You only have look at the properties of the file > to see (visibly) that there is no digital signature. > > So I must ask, why do we bother sign the *.exe that's in the zip file is > it's not a problem for it not to be signed? > > In the end, *I* have a concrete issue with this. The installer (and p2 > director) does not (and cannot) produce an installation with signed > executables. I.e., it doesn't produce something that's equivalent to the > distributed zipped packages. I'm not comfortable that and I'm a user too, so > it seems odd that I am not permitted to report it as a problem. > > So I don't get this attitude at all. Resolving this as invalid when that > flies in the fact of the reality seems totally inappropriate to me. > > This may well require downstream changes in the build processes, but now is > the time to make sure that all works properly. > > Please don't return this as invalid. I second Ed's opinion. What we ship should be signed not regarding through which channel it's shipped (packager, installer or remote update). If an artefact is not signed users can't be sure if it's really originating from Eclipse.
Ed and Matthias: can you confirm that signing them won't impact projects that want to brand and sign the executable? Also, do you know whether this is Windows only?
No, we cannot (In reply to Dani Megert from comment #7) > Ed and Matthias: can you confirm that signing them won't impact projects > that want to brand and sign the executable? Also, do you know whether this > is Windows only? Let's assume this does impact projects that want to rebrand and therefore (presumably) will need to resign. Is that then a reason not to do it? It would seem to me to be "simply" a problem that would also need to be solved. I.e., a signature remover or a signing service that can resign... I don't understand the signing processes for other platforms. I'm not a Tycho/Maven expert. I suspect that Linux is very similar and that Mac is quite different, but I don't know. Has this reverted to invalid state again? I'll reopen again assuming that I forgot to do that the last time.
IMHO, any binary/executable produced by the foundation should be signed and sealed, for security and authenticity purposes. If another project or third-party consumer wants to rebrand/resign a binary, they should rebuild from source.
(In reply to Denis Roy from comment #9) > IMHO, any binary/executable produced by the foundation should be signed and > sealed, for security and authenticity purposes. If another project or > third-party consumer wants to rebrand/resign a binary, they should rebuild > from source. Denis, I tend to agree, but note that Dani's very legitimate concern is that the EPP packages also rebrand the executable(s) provided by the platform. Similarly the Oomph installer also does that. So we can't realistically tell anyone (downstream projects and other downstream consumers) that they should rebuild from source, especially given that build native executables is a nightmare! So I share Dani's concern about the downstream impact of signing the executables but I think that's something "we" collectively need to investigate because signing is a certification of origin and that's seems to me always to be important...
OK, so let's sign the executables as a first step. Maybe clients will have to find a way to consume those afterwards. Sravan, please also check the current state for Mac and Linux executables.
I can assess the impact of any of such changes relatively quickly when building the installer against platform 4.13 I build. Of course I'll need to figure out what needs to change in the pom.xml so that we do the same thing as the platform to make sure that our branded executables are also signed.
(In reply to Dani Megert from comment #11) > OK, so let's sign the executables as a first step. Maybe clients will have > to find a way to consume those afterwards. > > Sravan, please also check the current state for Mac and Linux executables. Dani, Here is the status of signing Linux: We do not sign launcher either in the p2 repo or products (SDK, platform and equinox) Mac: Individual launcher executables are not signed. We layout products in mac app layout format and sign whole product folder. then we create a dmg and sign dmg again. Widows: Launcher is not signed in p2 repo. Signed in products
(In reply to Ed Merks from comment #12) > I can assess the impact of any of such changes relatively quickly when > building the installer against platform 4.13 I build. Of course I'll need > to figure out what needs to change in the pom.xml so that we do the same > thing as the platform to make sure that our branded executables are also > signed. Two questions: 1) As you mentioned, the installer is signed. Is this because you don't brand it and just use the eclipse.exe from a platform binary, or do you actually sign it? 2) If you say "branded executable", do you mean your installer, or the thing that the installer produces? If the latter, how is it signed today? Or is it currently not signed?
(In reply to Sravan Kumar Lakkimsetti from comment #13) > Mac: > Individual launcher executables are not signed. We layout products in mac > app layout format and sign whole product folder. then we create a dmg and > sign dmg again. That could be a tough one. > Widows: > Launcher is not signed in p2 repo. Signed in products Let's start with this one.
(In reply to Dani Megert from comment #14) > Two questions: > > 1) As you mentioned, the installer is signed. Is this because you don't > brand it and just use the eclipse.exe from a platform binary, or do you > actually sign it? > It's complicated by the different platforms. On Windows, "the installer" is distributed as a native executable that is signed (this is similar to the *.dmg on the Mac). That executable effectively embeds a zip file of an installer RCP application/product (this is similar to the zipped downloads of the platform SDK on an EPP package/product). We don't do anything explicit to sign the executable in that zip, but I tested and it is definitely signed, so on Windows both the wrapping executable and the embedded RCP/product executable are signed). On Linux we just deliver a tar.gz, but I believe (though can't verify because I don't know how) that it too has a signed executable (just like on Windows) because Tycho just does that for us. And on the Mac, it's exactly like what is described for the platform, we build a Mac executable format, sign the App, and then DMG it (though I don't know about signing the DMG itself). Again, I don't know how to verify that any of this is actually working correctly on the Mac, though I suspect on the Mac would refuse to run it if all the things aren't already properly done. > 2) If you say "branded executable", do you mean your installer, or the thing > that the installer produces? I mean this in exactly the same way as the EPP packages often/typically brand the executable. Note again that the installer, in the end, is effectively just p2 director and it just installs/copies things from p2 repos onto the local filesystem. It does not brand and it does not sign, it merely installs what's specified in/by the p2 repo. > If the latter, how is it signed today? Or is it > currently not signed? What the installer produces, i.e., the installation it creates (or what p2 director creates) is purely based on what's in the p2 repository. Clearly the installer (p2 director) cannot and do not provide a signing service, nor a branding service. Signing is a certification or origin and must be done at the origin. Branding is also done at the origin. So if the installer is to produce signed results (where all the jars are signed and the executables are signed), it must get those in signed form from the origin.
Note that I just got my first integration build https://ci.eclipse.org/oomph/job/integration/ running against the 4.13-I-builds, and this signing does not appear to have caused any problems. But I don't know the underlying Tycho behavior either. I.e., where does Tycho get the eclipse.exe and eclipsec.exe that it uses to build a *.product? Does anyone know this. Of course the (branded) executable in my repo isn't signed either. https://ci.eclipse.org/oomph/job/integration/ws/products/repository/binary/org.eclipse.oomph.setup.installer.product.executable.win32.win32.x86_64_1.14.0.v20190624-1329 What changed did you change in the platform's build (pom files?) to ensure that the executable in the repository is actually signed now? I will need to make that same change and so will the EPP builds. But looking at /home/data/httpd/download.eclipse.org/eclipse/updates/4.13-I-builds/I20190607-0725/binary/org.eclipse.platform.sdk.executable.win32.win32.x86_64_4.13.0.I20190607-0725 I don't see that this or any of the other ones actually are signed. So, which executables are being signed before they are published into the repository and how are you doing that?
(In reply to Ed Merks from comment #17) > Note that I just got my first integration build > > https://ci.eclipse.org/oomph/job/integration/ > > running against the 4.13-I-builds, and this signing does not appear to have > caused any problems. But I don't know the underlying Tycho behavior either. > I.e., where does Tycho get the eclipse.exe and eclipsec.exe that it uses to > build a *.product? > > Does anyone know this. > > Of course the (branded) executable in my repo isn't signed either. > > https://ci.eclipse.org/oomph/job/integration/ws/products/repository/binary/ > org.eclipse.oomph.setup.installer.product.executable.win32.win32.x86_64_1.14. > 0.v20190624-1329 > > What changed did you change in the platform's build (pom files?) to ensure > that the executable in the repository is actually signed now? I will need > to make that same change and so will the EPP builds. > > But looking at > /home/data/httpd/download.eclipse.org/eclipse/updates/4.13-I-builds/ > I20190607-0725/binary/org.eclipse.platform.sdk.executable.win32.win32. > x86_64_4.13.0.I20190607-0725 I don't see that this or any of the other ones > actually are signed. > > So, which executables are being signed before they are published into the > repository and how are you doing that? We haven't signed the executables yet. We are still trying to figure out exactly where to put signing code. Hope fully by thursday we should get this out.
(In reply to Sravan Kumar Lakkimsetti from comment #1) > We use winsigner > plugin(https://www.eclipse.org/cbi/sitedocs/eclipse-winsigner-plugin/sign- > mojo.html) to sign windows executables this is done as part of building > Platform, sdk and equinox products. > > Here is pom.xml for SDK > producthttps://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator. > git/tree/eclipse.platform.releng.tychoeclipsebuilder/sdk/pom.xml > > In this case we have tied winsigner plugin to package phase. The problem is > there are multiple goals tied to package phase > > like > tycho-p2-repository:assemble-repository > tycho-p2-repository:archive-repository > tycho-p2-director:materialize-products > tycho-p2-director:archive-products > > we need to run eclipse-winsigner-plugin:sign before > tycho-p2-repository:archive-repository. currently it is running before > tycho-p2-director:archive-products > > Need to rationalize maven phase selection with these goals. > > @mat > Can you please help in this? If we simply need to ensure that the sign goal executes before anything in the "package" phase, you can simply bind it to the "prepare-package" phase instead.
New Gerrit change created: https://git.eclipse.org/r/144909
I modified the launcher build process to sign windows executable while building the launcher. Created new windows launcher though https://git.eclipse.org/c/equinox/rt.equinox.binaries.git/commit/?id=8f4c91e1e3ff65c82e8b176c35f13555fcfe4ff7 Tonight's build should have signed executables in p2 repositories.
New Gerrit change created: https://git.eclipse.org/r/144920
There are some version issues after launcher rebuild. Patch to follow
New Gerrit change created: https://git.eclipse.org/r/144962
Gerrit change https://git.eclipse.org/r/144962 was merged to [master]. Commit: http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?id=b15831707aac5919aaecff24c3126ae72666fc3e
merged version updates to master
During verification noticed eclipse.exe has invalid signature. Rebuilt launchers with https://git.eclipse.org/c/equinox/rt.equinox.binaries.git/commit/?id=a286f5865744ce59cafc4c2ec3e763856316121f Need to verify in tonight's build
Reopening as we are still getting "Verified: The digital signature of the object did not verify." error for eclipse.exe. eclipsec.exe does not have this problem. Investigating
The executables available at source(https://git.eclipse.org/c/equinox/rt.equinox.binaries.git/tree/org.eclipse.equinox.executable/bin/win32/win32/x86_64) are signed. There is some problem during the repo build which is causing the signature to invalid.
New Gerrit change created: https://git.eclipse.org/r/145281
Gerrit change https://git.eclipse.org/r/145281 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/commit/?id=69c1541baa1e4c801e0aa005ed90463aa98072d7
New Gerrit change created: https://git.eclipse.org/r/145300
Gerrit change https://git.eclipse.org/r/145300 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/commit/?id=fcc1c868b3d4445ed3d7b3b75f8a4221495f8818
New Gerrit change created: https://git.eclipse.org/r/145318
Gerrit change https://git.eclipse.org/r/145318 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/commit/?id=6e21c49038cf0e95cc6b6a34c7cfcaaf26ecf835
New Gerrit change created: https://git.eclipse.org/r/145319
Gerrit change https://git.eclipse.org/r/145319 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/commit/?id=5057f35e0b6dd3ba7f46108d0ec515b6851b3abd
New Gerrit change created: https://git.eclipse.org/r/145347
Gerrit change https://git.eclipse.org/r/145347 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/commit/?id=af870bb8f1b1611954967668a1f71e3f315c64ce
After investigation the following is my observations on solving this issue. We do have signing service available from cbi(https://www.eclipse.org/cbi/sitedocs/eclipse-winsigner-plugin/sign-mojo.html). Most of the parameters mentioned here are to be passed to signing service 1. tycho-p2-publisher-plugin::publish-products needs to be updated to accept three more parameters * sign true/false (sign the launcher executables) * signer url (signer service url) * timeout (timeout for the signing service) * retry limit (number of times the signing should be tried) * retry timer (waiting time before retry) 2. PDE product packager needs to be enhanced to sign windows executables after the replacement of icons in the launcher. for signing one can use windows signing service from CBI. The parameter mentioned in tycho would be required for signing. Currently I am working on a workaround.
New Gerrit change created: https://git.eclipse.org/r/145362
Gerrit change https://git.eclipse.org/r/145362 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/commit/?id=b36f5cf61abead17034045e763ec5b5bcea0d992
The latest workaround of signing binaries after the repository is built failed as the checksums in artefacts.xml won't match. Reverting this workaround The only workaround I can think of now is to remove icon file from the product files. The drawback is rt.exe will show eclipse icon instead of equinox icon. I think this would be acceptable workaround till 548893 is fixed.
New Gerrit change created: https://git.eclipse.org/r/145402
Gerrit change https://git.eclipse.org/r/145402 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/commit/?id=96d00dd9f4104eeb4c65198972efd8d7d5733848
New Gerrit change created: https://git.eclipse.org/r/145406
Gerrit change https://git.eclipse.org/r/145406 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/commit/?id=8507d427bb50cb0fde4ec6a8ed1512abf0ee4938
Personally I would simply wait until https://bugs.eclipse.org/bugs/show_bug.cgi?id=548893 is fixed because workarounds are painful and time consuming. Furthermore, everyone downstream also will have these same problems so really need to be properly addressed by the "normal" Tycho build. In particular the EPP builds will have this same issue (as will Oomph with the installer executable) so it would seem best to solve this problem once and for all in a reusable way for all of the projects build and/or branding executables... But that's just my opinion...
workaround added in comment 46 worked. This problem needs to be addressed by PDE project builder. Tycho would be a conduit between user and PDE project builder. As of now epp packages do not replace launcher icon so there should be no problem in epp pakages or in upgrades. Oomph installer does have icon replacement so eclipse installer will have problems. I agree with ed on fixing 548893 and 548894 to properly fix this issue. Till that time only available workaround I have is to remove windows icon replacement from product configuration.
I can confirm that installing the latest platform SDK product with Oomph now results in an installation with both the eclipse.exe and the eclipsec.exe being signed. I've not noticed any problems in the Oomph nightly build from last night; I'll check those results again tomorrow, but our self-extracting installer is still branded and signed and the eclipse-inst.exe embedded in that is also still branded and signed...
It seems odd, but when I look in the repo for the most recent Oomph build, in particular at https://ci.eclipse.org/oomph/job/integration/lastBuild/artifact/products/repository/binary/ The eclipse-inst.exe in the binary org.eclipse.oomph.setup.installer.product.executable.win32.win32.x86_64_* is signed. And when I use the installer to create an installer from this repository the results on the file system are also signed and branded. And that installer's installation launches and runs fine.. I'm not sure why this all just works, but it does appears to be working properly. Likely the EPP packages will just work too, especially if they just reuse the signed executables provided by the platform... What is still not the case is that any of the *.dll files are signed by anyone. At least in the case of Oomph's one *.dll, I believe we just need to commit a signed version rather than the current unsigned version to address this remaining issue.
(In reply to Ed Merks from comment #51) > It seems odd, but when I look in the repo for the most recent Oomph build, > in particular at > > https://ci.eclipse.org/oomph/job/integration/lastBuild/artifact/products/ > repository/binary/ > > The eclipse-inst.exe in the binary > > org.eclipse.oomph.setup.installer.product.executable.win32.win32.x86_64_* > > is signed. > > And when I use the installer to create an installer from this repository the > results on the file system are also signed and branded. And that > installer's installation launches and runs fine.. > > I'm not sure why this all just works, but it does appears to be working > properly. > > Likely the EPP packages will just work too, especially if they just reuse > the signed executables provided by the platform... > > What is still not the case is that any of the *.dll files are signed by > anyone. At least in the case of Oomph's one *.dll, I believe we just need > to commit a signed version rather than the current unsigned version to > address this remaining issue. When I ran signature check tool from sysinternals(https://docs.microsoft.com/en-us/sysinternals/downloads/sigcheck) on the binary from https://ci.eclipse.org/oomph/job/integration/lastBuild/artifact/products/repository/binary/ I get C:\Users\IBM_ADMIN\Desktop\eclipse-inst.exe: Verified: The digital signature of the object did not verify. Link date: 12:03 PM 27-Jun-19 Publisher: n/a Company: n/a Description: n/a Product: n/a Prod version: n/a File version: n/a MachineType: 64-bit C:\Users\IBM_ADMIN\Desktop\eclipsec.exe: Verified: Signed Signing date: 12:03 PM 27-Jun-19 Publisher: Eclipse.org Foundation, Inc. Company: n/a Description: n/a Product: n/a Prod version: n/a File version: n/a MachineType: 64-bit This means the file is signed but the signature is not valid any more. To resolve this we need 548893 fixed. The reason why it happens is the exe files are signed when thy are built in the launcher build process. And during product build the icon for launcher(eclipse.exe/eclipse-inst.exe) gets replaced with icon specified in the product configuration rendering the signature invalid. This launcher is added to the repository. So when we use repository to build a new product or upgrade existing product we get launcher with invalid signature. In the product build process we do layout eclipse product and sign the executables again. this creates a new signature on the executable. We make this available as eclipse-installer.exe or as platform product or SDK product. So these do not have invalid signature problem.
Thanks so much for this detailed information and the links! And also for all the effort you invested in this so far!! Note that I created this job to sign Oomph's one DLL https://ci.eclipse.org/oomph/job/dll-signer/ It produces this result: https://ci.eclipse.org/oomph/job/dll-signer/lastSuccessfulBuild/artifact/jreinfo.dll And that appears to pass the sigcheck64 test. I've also tested locally that it still actually works. :-) Do you think that the right approach is to commit such a signed DLL to the Git repo? We currently have the unsigned version committed so it seems sensible just to commit a signed version of it rather than to try to do signing during the build. But I would be happy to know your thoughts on such an approach.
(In reply to Ed Merks from comment #53) > Thanks so much for this detailed information and the links! And also for > all the effort you invested in this so far!! > > Note that I created this job to sign Oomph's one DLL > > https://ci.eclipse.org/oomph/job/dll-signer/ > > It produces this result: > > https://ci.eclipse.org/oomph/job/dll-signer/lastSuccessfulBuild/artifact/ > jreinfo.dll > > And that appears to pass the sigcheck64 test. I've also tested locally that > it still actually works. :-) > > Do you think that the right approach is to commit such a signed DLL to the > Git repo? We currently have the unsigned version committed so it seems > sensible just to commit a signed version of it rather than to try to do > signing during the build. But I would be happy to know your thoughts on > such an approach. IMHO this would be correct approach. I would add signing to dll build process itself rather than running it separately. You can use exec-maven-plugin to run this command from maven. This is exactly what I am doing in the launcher build. I commit signed executables into launcher binaries repo https://git.eclipse.org/c/equinox/rt.equinox.binaries.git/tree/org.eclipse.equinox.executable/bin/win32/win32/x86_64
Yes, if we had a process to build the DLL, it would of course make sense to add signing to that process, but the DLL is built manually locally and that result is committed after the manual process. Thanks again!
Added signed launcher bundles (.exe and .dll files) through https://git.eclipse.org/c/equinox/rt.equinox.binaries.git/commit/?id=7333db54bc8f4ec6f43079346c9f8f287b6d4c7f
Modified swt build process to build signed native libraries for windows
Sravan, Do you know if there a tool that can run on Linux (i.e.,the build server) that can verify the validity of a signed *.exe/*.dll?
(In reply to Ed Merks from comment #58) > Sravan, > > Do you know if there a tool that can run on Linux (i.e.,the build server) > that can verify the validity of a signed *.exe/*.dll? The tool that is used to sign the exe (https://github.com/develar/osslsigncode) says: "You can check that the signed file is correct by right-clicking on it in Windows and choose Properties --> Digital Signatures, and then choose the signature from the list, and click on Details. You should then be presented with a dialog that says amongst other things that "This digital signature is OK"." So I guess that there is no such CLI Linux tool.
(In reply to Mikaël Barbero from comment #59) > (In reply to Ed Merks from comment #58) > > Sravan, > > > > Do you know if there a tool that can run on Linux (i.e.,the build server) > > that can verify the validity of a signed *.exe/*.dll? > > The tool that is used to sign the exe > (https://github.com/develar/osslsigncode) says: > > "You can check that the signed file is correct by right-clicking > on it in Windows and choose Properties --> Digital Signatures, > and then choose the signature from the list, and click on > Details. You should then be presented with a dialog that says > amongst other things that "This digital signature is OK"." > > So I guess that there is no such CLI Linux tool. Of course if the process of validating signatures is going to be a manual one, I imagine it's really not going to get done at all. :-( Is there a possibility to build a service that uses this tool: https://docs.microsoft.com/en-us/sysinternals/downloads/sigcheck and farms such a checking process out to a Windows machine? Then we'd be able to automate the validation of a repository's contents...
Even though we try to avoid running CBI services on non linux hosts (it really is complicated to provide a reliable service on mac/windows), I can see the value of such a tool. Could you please open a ticket against CBI? Also, please, keep your expectations low on when this can be done. Still, I'd like such a request to be tracked. Thanks.
(In reply to Mikaël Barbero from comment #59) > (In reply to Ed Merks from comment #58) > > Sravan, > > > > Do you know if there a tool that can run on Linux (i.e.,the build server) > > that can verify the validity of a signed *.exe/*.dll? > > The tool that is used to sign the exe > (https://github.com/develar/osslsigncode) says: > > "You can check that the signed file is correct by right-clicking > on it in Windows and choose Properties --> Digital Signatures, > and then choose the signature from the list, and click on > Details. You should then be presented with a dialog that says > amongst other things that "This digital signature is OK"." > > So I guess that there is no such CLI Linux tool. looks like we can use same tool to verify as well ref https://unix.stackexchange.com/questions/269906/how-can-i-extract-signatures-data-from-a-windows-exe-file-under-linux-using-cl
Even better. No need for additional service. /opt/public/common/osslsigncode-1.6 is available on all JIPP (old infra). Feel free to use it to check the signatures.
(In reply to Mikaël Barbero from comment #63) > Even better. No need for additional service. > > /opt/public/common/osslsigncode-1.6 is available on all JIPP (old infra). > Feel free to use it to check the signatures. We are getting this error when we try in the job /opt/public/common/osslsigncode-1.6: error while loading shared libraries: libgsf-1.so.114: cannot open shared object file: No such file or directory Can please have a look?
I guess it's when you run the job on centos agents? Please try to run it on Jenkins master.
My bad, it happens also on masters. This binary has been compiled on build and is not runnable on hipps machine. I guess you will have to compile it by yourself and use the output binary.
It seems that the changes for this bug had as side-effect that also the SWT-DLLs are signed now, see Bug 529428. However there are some more DLLs in the Eclipse environment, will the automatically be singed when re-compiled or is more configuration needed? At least: - jnicrypt64.dll (org.eclipse.equinox.security) - win32refresh.dll (org.eclipse.core.resources) - localfile_1_0_0.dll (org.eclipse.core.filesystem) - jWinHttp-1.0.0.dll (org.eclipse.core.net)
(In reply to Rolf Theunissen from comment #67) > It seems that the changes for this bug had as side-effect that also the > SWT-DLLs are signed now, see Bug 529428. > > However there are some more DLLs in the Eclipse environment, will the > automatically be singed when re-compiled or is more configuration needed? > At least: > - jnicrypt64.dll (org.eclipse.equinox.security) > - win32refresh.dll (org.eclipse.core.resources) > - localfile_1_0_0.dll (org.eclipse.core.filesystem) > - jWinHttp-1.0.0.dll (org.eclipse.core.net) Signing of dlls is expected change they were achieved by making changes to respective build jobs. The expectation is to sign all dlls used in eclipse environment. Thank you for providing list of unsigned dlls. I will sign them shortly.
New Gerrit change created: https://git.eclipse.org/r/147534
New Gerrit change created: https://git.eclipse.org/r/147535
New Gerrit change created: https://git.eclipse.org/r/147536
Gerrit change https://git.eclipse.org/r/147536 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.team.git/commit/?id=ab8841ea6c504ad3409788ee2ca78869e8954939
Gerrit change https://git.eclipse.org/r/147534 was merged to [master]. Commit: http://git.eclipse.org/c/equinox/rt.equinox.bundles.git/commit/?id=cf55f82da620d4456aa894396d4bf52e9383f62f
Gerrit change https://git.eclipse.org/r/147535 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.resources.git/commit/?id=adb21d8918b40437e4f89f8f65ac7f4143aeb973
We have a workaround in place for 4.13. Moving to 4.14 as the dependent bugs are not completed yet
What's the status here?
(In reply to Dani Megert from comment #76) > What's the status here? We are waiting for Bug 548893 and 548894 to be closed.
(In reply to Sravan Kumar Lakkimsetti from comment #77) > (In reply to Dani Megert from comment #76) > > What's the status here? > > We are waiting for Bug 548893 and 548894 to be closed. Let's not just "wait". Please push on the other bugs and bring this to an end.
Moving out of 4.14
Dependent bugs are not yet worked on. Removing target
(In reply to Sravan Kumar Lakkimsetti from comment #80) > Dependent bugs are not yet worked on. Removing target Please push on this.
This did not get fully delivered for 4.16. The work continues in plan bug 564820.
Complete dthe required work in bug 564820
