you're right no need for this to happen now, consider it postponed. Sent from my Samsung device. Include original message ---- Original message ---- From: Patricia Shanahan <p...@acm.org> Sent: 08/04/2016 11:15:44 pm To: dev@river.apache.org Subject: Re: [DISCUSS] [vote] should we fix security flaws?
I am curious not so much about why a vote as about why a vote at this particular time I thought we had a consensus in favor of a future direction discussion after the River 3.0 release. I was thinking about how to facilitate constructive communication with a view to reaching a consensus wherever possible. That should include everyone listening to your security concerns, and considering them in the light of actual use-cases for River. Even though you have time available now that cannot be applied to River 3.0, I am not at all sure that is true for everyone. I attributed the lack of release progress to people being too busy. Is there any way you could consider delaying this vote until the end of the post-release future direction discussion, and then only holding it if we fail to reach consensus? On 4/8/2016 12:29 AM, Peter wrote: > To provide some context on why I've put this to a vote: > > Previous arguments against fixing security have suggested it's not relevant >to local networks where River is deployed. > > But I've received some mixed messages regarding security recently. > > Although we can never fully guarantee complete security, we can address known >issues if we choose to. > > Having this vote will help clarify whether security is important or not to >the community. > > Once that is determined it will be easier to guage whether the time and >effort in creating proofs for the existance of vulnerabilities is worthwhile. > > Regards, > > Peter. > > Sent from my Samsung device. > > Include original message > ---- Original message ---- > From: Peter <j...@zeus.net.au> > Sent: 08/04/2016 11:38:40 am > To: dev@river.apache.org <d...@riverapache.org> > Subject: Re: [DISCUSS] [vote] should we fix security flaws? > > > I don't think we should delay the release to fix security. > > You have your reasons for not voting and I respect that. > > Fixing security isn't technically difficult and I have fixes available, >I'm hoping for collaborative development, so they receive peer review / >modification / alternate solutions / suggestions / feedback / rejection etc. > > I haven't been successful communicating / discussing security and I think >that will take some time to sort out. > > The ability to take down servers using dos is annoying and easily >demonstrated (I've started writing some code to do so), however Gadget attacks >allow an attacker to take over systems, steal data etc, but are less easily >demonstrated. While there are existing known gadget attacks, the ones I'm >aware of have fixes, so I'll be looking for a zero day to demonstrate. While >whack a mole is one approach to fixes, it would be better to provide an api to >support input validation. > > http://frohoff.github.io/appseccali-marshalling-pickles/ > > Gadget attacks create object graphs using existing local classes to create >execution paths that perform malicious actions during deserialization, this is >a relatively recent development. Security advisories recommend against >deserializing from untrusted sources. > > The intent of the vote request is to determine whether fixing security issues >is an option in future. > > If the result is no, it's my intention is to focus on getting River off svn >into git, so it's easier to maintain my own branch while sharing and >contributing to a common code base. > > If yes then I'll work on improving my communication skills for discussing >security related issue's. > > Discussing this won't hold up a release as the time windows available for me >to work on producing a release are weekends only. I'm going to have to create >the release artifacts on MSWindows, so need to check the scripts work properly >and understand recent build changes. > > I also have other goals, I'll be ready to set up a public service registrar, >discoverable over ipv6 in the near future. > > If the no vote wins, I promise not to mention security on this list again. > > Regards, > > Peter. > > Sent from my Samsung device. > > Include original message > ---- Original message ---- > From: Patricia Shanahan <p...@acm.org> > Sent: 08/04/2016 06:34:23 am > To: dev@riverapacheorg > Subject: [DISCUSS] [vote] should we fix security flaws? > > I am not prepared to vote on this. > > First of all, I would need, on a private list where we can go into > details of security issues, to get a feeling for the seriousness of the > flaws in question. A denial of service is, in many contexts, less > serious than file corruption. > > We may want to consider investigating the actual and proposed use-cases > for River before deciding this. > > Do you feel any of the security flaws in question are release-blockers > for River 3.0? How long would fixing them first delay the release? > > On 4/7/2016 12:36 PM, Peter wrote: >> How do people on this project feel about security flaws? >> >> Should we be fixing them? >> >> I can provide evidence of vulnerabilities, I'm not proposing my fixes be >>adopted >> >> Vote: >> >> +1 Yes we should aim to fix security flaws. >> 0 don't care. >> -1 No. >> >> Regards, >> >> Peter. >> >> >> >> Sent from my Samsung device. >> >> > > > > >
