Re: [DISCUSS] [vote] should we fix security flaws?
Thank you. After the release, during the future direction discussion, I'll support discussing this issue to try to at least get mutual understanding, if not consensus. On 4/8/2016 9:59 AM, Peter wrote: 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 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 Sent: 08/04/2016 11:38:40 am To: dev@river.apache.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 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
Re: [DISCUSS] [vote] should we fix security flaws?
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 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 > Sent: 08/04/2016 11:38:40 am > To: dev@river.apache.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 > 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 p
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 Sent: 08/04/2016 11:38:40 am To: dev@river.apache.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 Sent: 08/04/2016 06:34:23 am To: dev@river.apacheorg 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.
Re: [DISCUSS] [vote] should we fix security flaws?
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 Sent: 08/04/2016 11:38:40 am To: dev@river.apache.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 Sent: 08/04/2016 06:34:23 am To: dev@river.apacheorg 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. > >
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 Sent: 08/04/2016 06:34:23 am To: dev@river.apache.org 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. > >
[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.
[vote] should we fix security flaws?
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.
