4 ms·

> Jenkins probably contain the key to the svn server Why should it? For open-source software build-server can even be ran by a third party.

yeukhon 11y ago
I am not following your comment here. Most Jenkins setup use global credentials or use the server-side config file like .ssh/config, .gitconfig link.
- conradev 11y ago
  But ideally there are no credentials because Jenkins doesn't need to push code to the repo (and can clone the pubically available code).
  - Matt3o12_ 11y ago
    But it might need to push new (binary) updates if the master/deploy branches gets updated or a commit contains a specific tag. As far as I know, only the binary was updated. I'd be interested to hear, though, how it got compromised after all.
    - conradev 11y ago
      Yeah, that makes sense. Build servers are one of the weakest links in distributing software. That's why this exists and I'm glad it's making progress: https://reproducible-builds.org https://reproducible-builds.org And even if you sign updates, the key management for doing that is usually centralized, which can be bad: http://arstechnica.com/security/2016/02/most-software-already-has-a-golden-key-backdoor-its-called-auto-update/ http://arstechnica.com/security/2016/02/most-software-alread...
      - Matt3o12_ 11y ago
        I do not think it was the build server, though. According to this analysis[1], the developer used a different key to sign the build (all Mac apps need to be signed or the default behavior is to reject that App. You can permanently disable this behavior in settings, or just for on app by holding control while opening the App, which a lot users who use transmission probably do because not all legitimate Apps are signed). Anyways, since the app was signed by a third party's certificate (which was approved by Apple), chances are only the website was compromised. If the build server had been compromised, the attack would have had access to the developer's certificate and they would most likely have used that. [1]: http://researchcenter.paloaltonetworks.com/2016/03/new-os-x-ransomware-keranger-infected-transmission-bittorrent-client-installer/ http://researchcenter.paloaltonetworks.com/2016/03/new-os-x-...

yeukhon 11y ago

I am not following your comment here. Most Jenkins setup use global credentials or use the server-side config file like .ssh/config, .gitconfig link.

conradev 11y ago
But ideally there are no credentials because Jenkins doesn't need to push code to the repo (and can clone the pubically available code).
- Matt3o12_ 11y ago
  But it might need to push new (binary) updates if the master/deploy branches gets updated or a commit contains a specific tag. As far as I know, only the binary was updated. I'd be interested to hear, though, how it got compromised after all.
  - conradev 11y ago
    Yeah, that makes sense. Build servers are one of the weakest links in distributing software. That's why this exists and I'm glad it's making progress: https://reproducible-builds.org https://reproducible-builds.org And even if you sign updates, the key management for doing that is usually centralized, which can be bad: http://arstechnica.com/security/2016/02/most-software-already-has-a-golden-key-backdoor-its-called-auto-update/ http://arstechnica.com/security/2016/02/most-software-alread...
    - Matt3o12_ 11y ago
      I do not think it was the build server, though. According to this analysis[1], the developer used a different key to sign the build (all Mac apps need to be signed or the default behavior is to reject that App. You can permanently disable this behavior in settings, or just for on app by holding control while opening the App, which a lot users who use transmission probably do because not all legitimate Apps are signed). Anyways, since the app was signed by a third party's certificate (which was approved by Apple), chances are only the website was compromised. If the build server had been compromised, the attack would have had access to the developer's certificate and they would most likely have used that. [1]: http://researchcenter.paloaltonetworks.com/2016/03/new-os-x-ransomware-keranger-infected-transmission-bittorrent-client-installer/ http://researchcenter.paloaltonetworks.com/2016/03/new-os-x-...