Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

[PROCEDURES] Security policy #4113

Merged
merged 11 commits into from Jun 28, 2017

Conversation

Projects
None yet
@erasche
Copy link
Member

commented May 24, 2017

FAQ:

  • Who has time for this?
    • I volunteer as tribute.
    • @jmchilton would as well, if there was support from the PIs. xref #4071 (comment)
    • I'm sure that we are not alone in this.
  • This is a big commitment
    • Indeed! Time to build a security sub-team who can share duties.
    • The biggest time commitment is testing against old versions of galaxy and ensuring patches work. Hopefully his can be atmeliorated by jenkins (or travis) test matricies and spending time build reported security faults into PoC exploits that can be run and tested automatically.
  • 17.09:
    • Unless there is just overwhelming support, I'll be available at GCC to defend this as useful and necessary.
  • "we're already short on time, why is this worth devoting time to?
    • my (initial) counters are, in brief:
      • deployers and their universities care (see automated scan reports people send)
      • based on committers mailing list traffic this will be low commitment unless the individuals are enthusiastic about adding more features
      • we're constantly adding new attack vectors features like GIEs. If there's a team of security minded folks, we have some points of contact for "hey would this make things worse in terms of security? How can we make this feature more palatable for admins and security folks? Is there documentation we should add that people should be aware of?"

This is being opened as a procedures PR because it really needs buy in from stakeholders. @jmchilton said it better than I can:

I'd also not merge this until a few people who actually fund Galaxy development sign off on it - perhaps we could ping the three PIs on the final real [PROCEDURES] PR and get at least a couple 馃憤s from them.

From my various hats:

  • As a developer, we should have an aggressive security posture and attack our own infrastructure regularly to ensure we're not shipping exploits to unsuspecting administrators.
  • As an admin, I want the sort of transparency and accountability described in this document.
  • As a white hat, I like the assurances that the team will respond to my vulnerability reports efficiently.

erasche and others added some commits May 16, 2017

Merge pull request #18 from nsoranzo/patch-1
Small enhancements to SECURITY_POLICY.md
@martenson

This comment has been minimized.

Copy link
Member

commented May 24, 2017

perhaps we could ping the three PIs on the final real [PROCEDURES] PR and get at least a couple 馃憤s from them

ping @nekrut @jxtx @jgoecks

@natefoo

This comment has been minimized.

Copy link
Member

commented May 24, 2017

+1 FIRST

@martenson

This comment has been minimized.

Copy link
Member

commented May 24, 2017

馃憤 thank you @erasche for putting this together

I appreciate the "who has time for this" section, but if this gets approved we as a committers team have to find the time I believe. I do not want to pinpoint this on individuals as an extra responsibility.

@nsoranzo

This comment has been minimized.

Copy link
Member

commented May 24, 2017

馃憤

@jxtx

This comment has been minimized.

Copy link
Contributor

commented May 25, 2017

Thanks for doing this @erasche. I think this is mostly consistent with what we've tried to do in the past, but it is nice to have everything made explicit -- and hard timelines. So... +1

@bgruening

This comment has been minimized.

Copy link
Member

commented May 26, 2017

馃憤

2 similar comments
@mvdbeek

This comment has been minimized.

Copy link
Member

commented May 30, 2017

馃憤

@blankenberg

This comment has been minimized.

Copy link
Member

commented May 31, 2017

+1

@jmchilton

This comment has been minimized.

Copy link
Member

commented Jun 1, 2017

馃憤

I'm nervous about making these commitments but I think they are probably the right thing to do. Thanks for pushing this @erasche.

@erasche

This comment has been minimized.

Copy link
Member Author

commented Jun 1, 2017

This has reached the 7 day / quorum thresholds. However, I would still love comments from @jgoecks / @nekrut.

Again, since this codifies some portion of their staff's time as committed to responding to security, it is important to me that they're on board.

Cheers john :)

@jgoecks

This comment has been minimized.

Copy link
Contributor

commented Jun 2, 2017

I'm concerned about the timelines and potential effort, but I'm all for trying this out and seeing if we can make it work. Thanks @erasche for moving this forward. +1

@nekrut nekrut merged commit dd0336e into galaxyproject:dev Jun 28, 2017

5 checks passed

api test Build finished. 276 tests run, 0 skipped, 0 failed.
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
framework test Build finished. 150 tests run, 0 skipped, 0 failed.
Details
integration test Build finished. 34 tests run, 0 skipped, 0 failed.
Details
toolshed test Build finished. 579 tests run, 0 skipped, 0 failed.
Details
@erasche

This comment has been minimized.

Copy link
Member Author

commented Jun 28, 2017

馃帀

@erasche erasche deleted the erasche:security-policy branch Aug 21, 2017

jmchilton added a commit to jmchilton/galaxy that referenced this pull request Oct 25, 2017

[PROCEDURES] Reduce weight of security policies for now.
I'd suggest we need more infrastructure in place to support this many releases - in particular we need more private testing of patches ahead of time (e.g. via Jenkins) and we need to ensure that all security patches (and indeed all features and bug fixes we wish to provide security support for) come in with regression tests.

The currently polices are not leading to more security testing, just more time patching old releases. I'm firmly of the belief that if it isn't tested it is broken so I don't see much value in security patches without tests.

On the off chance this is merged, once we have stronger policies regarding testings of components we wish to ensure security of and the means to run these tests on patches then I will be the first to open a PR to undo this change. I expect this policy change fails though - I just wanted to register my regret for +1'ing galaxyproject#4113 without policies and infrastructure for testing in place.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can鈥檛 perform that action at this time.