Hey Chris! I'm happy to clarify our use cases. Is there something specific I can detail?
We do have a private instance currently but do use JJB (integration/config)[0]. Do we have any private instances at WMF? This might be simplest and most secure. --stephen [0] We'll soon be running tests too https://gerrit.wikimedia.org/r/#/c/230260/ On Wed, Aug 12, 2015 at 11:33 AM, Chris Steipp <[email protected]> wrote: > Hi Michael / Stephen, > > Off the top of my head, I believe hashar setup something on our current > Jenkins instance to handle passwords. But nothing extreemly secret goes > there. > > There are a number of things we can do to mitigate common attacks. Let's > chat about the particular needs and some possible countermeasures we can > put into place. > > For background, is your team running its own jenkins instance currently? > > > On Wed, Aug 12, 2015 at 7:54 AM, Michael Holloway <[email protected] > > wrote: > >> (adding the security team) >> >> On Tue, Aug 11, 2015 at 6:54 PM, Stephen Niedzielski < >> [email protected]> wrote: >> >>> Hello all! I have one question: what is the recommend way to keep >>> files, such as a Java keystore, safe on a WMF Jenkins machine? >>> >>> The Android team is trying to automate as much as possible, especially >>> when it comes to releasing software. Our reasons aren't novel: manual >>> releases are time consuming, we worry about unintentionally shipping bad >>> bits, and we don't like doing it. One thing that's been blocking this >>> effort is a security concern over exposing confidential information, such >>> as signing certificates, login credentials, certain lists of strings, etc, >>> on a Jenkins server. >>> >>> It might be helpful to describe some of our concrete use cases. I know >>> them currently as: >>> >>> 1 Sign public jars with a private GnuPG key. >>> 2 Upload public jars to OSSRH with private credentials (currently >>> stored in a Gradle properties file but could be supplied on the command >>> line). >>> 3 Sign public Android apps with a private Java keystore. >>> >>> Our future use cases are likely to include: >>> >>> 4 Supply a private list of strings to generate private Android apps. >>> 5 Upload private and public Android apps to Google Drive (via >>> gdrive[0], requires a private app token). >>> 6 Upload public Android apps to the Google Play Developer Console >>> (TBD, likely requires a private app token). >>> 7 Upload public Android apps to the Amazon Appstore Developer >>> Portal (TBD, likely requires a private app token). >>> 8 Upload public Android apps to Caesium (via SCP). >>> 9 Update public release notes to a public MediaWiki installation. >>> 10 Publish public release notes to a mailing list. >>> >>> We currently do all of this on our local dev machines and it's a bit >>> scary. While generating the jars and apps on a build server as unsigned >>> artifacts would be a big win in itself, there would still be a significant >>> and error prone amount of signing and publishing we'd also prefer to live >>> in a controlled, reproducible environment. >>> >>> For simple strings, the Jenkins Mask Passwords Plugin[1] seems >>> promising, and even supported by Jenkins Job Builder[2]. What's not clear >>> is how to land files like our Java keystore and GnuPG keys on the server >>> securely. It's also not clear how we can guard our private Android app >>> artifacts mentioned in #4. >>> >>> In summary, we want to automate build and release and we want to keep >>> our private inputs and outputs secure. Surely other teams in the foundation >>> must have the same or very similar problems. What is the best reference >>> implementation? >>> >>> Thank you for reading! >>> >>> >>> --stephen >>> >>> [0] https://github.com/prasmussen/gdrive >>> [1] https://wiki.jenkins-ci.org/display/JENKINS/Mask+Passwords+Plugin >>> [2] >>> http://docs.openstack.org/infra/jenkins-job-builder/wrappers.html#wrappers.mask-passwords >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "android" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To post to this group, send email to [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/a/wikimedia.org/d/msgid/android/CANMtf2cEOHTPiYtPyvTO3Z0TipO6eHBrE%3Ds6q3HGKaFb0ki8TA%40mail.gmail.com >>> <https://groups.google.com/a/wikimedia.org/d/msgid/android/CANMtf2cEOHTPiYtPyvTO3Z0TipO6eHBrE%3Ds6q3HGKaFb0ki8TA%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >> >> >
_______________________________________________ QA mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/qa
