Security Vulnerable Dependency process

[Ken Finnigan]

All,

In today's MP Architecture call we discussed the issue of dependencies having security vulnerabilities and how we should manage that, as well as how many previous versions we should be retroactively fixing with an updated dependency. This came about because of a vulnerability that was present in a dependency for the Metrics TCK about a month or so ago.

Some of the ideas that were put forth include:

• Defining a period in which we, as a community, need to fix to a known vulnerability. By that I mean there's a new version of a dependency where a vulnerability was fixed, what is the period from that dependencies release before we should have a release of MP with that fix? What's an appropriate time frame? 2 weeks? 3 weeks?
• Do we have different rules for whether the vulnerable dependency is part of the API or the TCK? Does an API fix require a new minor, whereas a TCK fix is just a patch version?
• Does the Eclipse Security policy [1] come into play, and if so how? (From a read of it myself, it looks like this covers the case of a vulnerability in Eclipse project code directly as opposed to a vulnerability in a dependency)
• How many versions need to be patched and released? Current stream? Current stream and latest release? Current stream and X many previous releases?

Please provide thoughts and ideas.

The goal is to have some discussion about what a good process might include so that we can agree on it at a Live Hangout meeting.

Regards

Ken

[1] - https://www.eclipse.org/security/policy.php

[Ken Finnigan]

Anyone have absolutely any thoughts on this?

[Emily Jiang]

• Defining a period in which we, as a community, need to fix to a known vulnerability. By that I mean there's a new version of a dependency where a vulnerability was fixed, what is the period from that dependencies release before we should have a release of MP with that fix? What's an appropriate time frame? 2 weeks? 3 weeks?

I think we should pull in the version with the security fix asap.

• Do we have different rules for whether the vulnerable dependency is part of the API or the TCK? Does an API fix require a new minor, whereas a TCK fix is just a patch version?

For an API fix, I think we should release a minor version where TCK a patched version as TCKs are only executed by MP implementations and will not affect end users in any form.

• Does the Eclipse Security policy [1] come into play, and if so how? (From a read of it myself, it looks like this covers the case of a vulnerability in Eclipse project code directly as opposed to a vulnerability in a dependency)

I don't think so as we are talking about dependency vulnerability not the MP code per se. 

• How many versions need to be patched and released? Current stream? Current stream and latest release? Current stream and X many previous releases?

I think we should only patch the latest release and encourage customers to move up. As even though an older version of a spec (e.g. Metrics 1.x) does a minor update, no older MP umbrella release will be planned to include them. However, we can make exceptions under some extreme circumstances.

My 2cents.

Emily

[Ken Finnigan]

On Mon, Oct 28, 2019 at 5:48 PM 'Emily Jiang' via Eclipse MicroProfile <microp...@googlegroups.com> wrote:

• Defining a period in which we, as a community, need to fix to a known vulnerability. By that I mean there's a new version of a dependency where a vulnerability was fixed, what is the period from that dependencies release before we should have a release of MP with that fix? What's an appropriate time frame? 2 weeks? 3 weeks?

I think we should pull in the version with the security fix asap.

While I agree asap is important, I think we need to define a time frame otherwise it becomes a grey area. 

• Do we have different rules for whether the vulnerable dependency is part of the API or the TCK? Does an API fix require a new minor, whereas a TCK fix is just a patch version?

For an API fix, I think we should release a minor version where TCK a patched version as TCKs are only executed by MP implementations and will not affect end users in any form.

• Does the Eclipse Security policy [1] come into play, and if so how? (From a read of it myself, it looks like this covers the case of a vulnerability in Eclipse project code directly as opposed to a vulnerability in a dependency)

I don't think so as we are talking about dependency vulnerability not the MP code per se. 

• How many versions need to be patched and released? Current stream? Current stream and latest release? Current stream and X many previous releases?

I think we should only patch the latest release and encourage customers to move up. As even though an older version of a spec (e.g. Metrics 1.x) does a minor update, no older MP umbrella release will be planned to include them. However, we can make exceptions under some extreme circumstances.

My 2cents.

Emily

On Monday, October 28, 2019 at 9:04:53 PM UTC+1, Ken Finnigan wrote:

Anyone have absolutely any thoughts on this?

On Tue, Oct 8, 2019 at 3:47 PM Ken Finnigan <k...@kenfinnigan.me> wrote:

All,

In today's MP Architecture call we discussed the issue of dependencies having security vulnerabilities and how we should manage that, as well as how many previous versions we should be retroactively fixing with an updated dependency. This came about because of a vulnerability that was present in a dependency for the Metrics TCK about a month or so ago.

Some of the ideas that were put forth include:

• Defining a period in which we, as a community, need to fix to a known vulnerability. By that I mean there's a new version of a dependency where a vulnerability was fixed, what is the period from that dependencies release before we should have a release of MP with that fix? What's an appropriate time frame? 2 weeks? 3 weeks?
• Do we have different rules for whether the vulnerable dependency is part of the API or the TCK? Does an API fix require a new minor, whereas a TCK fix is just a patch version?
• Does the Eclipse Security policy [1] come into play, and if so how? (From a read of it myself, it looks like this covers the case of a vulnerability in Eclipse project code directly as opposed to a vulnerability in a dependency)
• How many versions need to be patched and released? Current stream? Current stream and latest release? Current stream and X many previous releases?

Please provide thoughts and ideas.

The goal is to have some discussion about what a good process might include so that we can agree on it at a Live Hangout meeting.

Regards

Ken

[1] - https://www.eclipse.org/security/policy.php

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/198e4197-f4d6-4a32-8066-6357dbb749a3%40googlegroups.com.

[Emily Jiang]

While I agree asap is important, I think we need to define a time frame otherwise it becomes a grey area.

I think 2-week time framework sounds reasonable as it will be just consuming the new third-party library. Obviously the corresponding TCKs should be executed by runtime to ensure everything is fine.

Thanks

Emily

To unsubscribe from this group and stop receiving emails from it, send an email to microp...@googlegroups.com.

[John Yeary]

Defining a period in which we, as a community, need to fix to a known vulnerability. By that I mean there's a new version of a dependency where a vulnerability was fixed, what is the period from that dependencies release before we should have a release of MP with that fix? What's an appropriate time frame? 2 weeks? 3 weeks?

The security policy is vague in that it mentions that they "Vulnerabilities for which there is a patch, workaround or fix, should be disclosed to the community immediately." They later note that the vulnerabilities do not need to be resolved at the time of disclosure. It also notes that timing is up to the project leadership. If, as Emily noted, that the fix is merely updating a third party library and running the TCK, then 2 weeks is very generous.

Do we have different rules for whether the vulnerable dependency is part of the API or the TCK? Does an API fix require a new minor, whereas a TCK fix is just a patch version?

I agree with Emily on this point too. It seems a reasonable approach.

Does the Eclipse Security policy [1] come into play, and if so how? (From a read of it myself, it looks like this covers the case of a vulnerability in Eclipse project code directly as opposed to a vulnerability in a dependency)

I believe that the Eclipse Security Policy is required. There is this particular line that makes me believe this to be true "This Security Policy applies to all software distributed by the Eclipse Foundation, including all software authored by Eclipse Committers and third-parties." The third-parties remark seems to me at least to include all dependencies in an Eclipse project.

How many versions need to be patched and released? Current stream? Current stream and latest release? Current stream and X many previous releases?

I would suggest the current stream, and last GA, or last two milestones if they are easily resolved with a library change. I would always suggest that the consumer should use the latest version, but reality indicates otherwise. 

Good discussion.

____________________________

John Yeary

____________________________ 

       

"Far better it is to dare mighty things, to win glorious triumphs, even though checkered by failure, than to take rank with those poor spirits who neither enjoy much nor suffer much, because they live in the gray twilight that knows not victory nor defeat."
-- Theodore Roosevelt

--

You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CAKeeVe5ZKp6RhO1A_uAN0foUBzFr6S7MGCc%3D-st-ZUbZbOEVbw%40mail.gmail.com.

[Amelia Eiras]

I think this topic needs to make it to the next Community call. :)