- Issue with Linux Foundation and expectations on ODL projects
Re: Issue with Linux Foundation and expectations on ODL projects
I missed the TSC meeting last night. Can someone recap over
email what came of
toggle quoted messageShow quoted text
this? I see one note in the minutes that Casey indicated that no
occurred in the policy regarding security violations, but that
accurate since Plastic v2.1.6 was successfully released, but
v2.1.7 is blocked
on security policies. Maybe I don't understand something, but that
Also, nobody is answering why the nexus IQ reports are failing
logs and messages about v2.1.6. Allan has mentioned that multiple
it keeps getting ignored.
On 3/5/20 7:01 PM, Thanh ha wrote:
On Thu, 5 Mar 2020 at 16:45, Anil Belur <abelur@...
On Fri, Mar 6, 2020 at 2:05 AM Allan <aclarke@...
have been trying to get a new release of the
Plastic sub-project out for 3 weeks now and
have been clogged up in LF helpdesk.
is not allowing newer release of Plastic 2.1.7
that fixes 3rd party
vulnerabilities already in 2.1.6 release.
wants ODL after-the-fact approval for Plastic
2.1.6 that is already publicly available.
LF tooling (Nexus IQ) and vulnerability
process is broken.
is the sequence of events AFAIKT:
2.1.6 released (months ago)
silently changes release process to require
Nexus IQ passing (no docs, no links to help
2.1.7 candidate build successful but not
available for testing
helpdesk says Nexus IQ violations making
version of Guava and Groovy have exposure on
features not used by Plastic)
finally gets accounts and links fixed so
Nexus IQ reports are available to PTL
version of Plastic 2.1.7 candidate build
still not available due to “violations”
IQ report is all screwed up in the UI,
mixing 2.1.6 and 2.1.7 up, mislabeling,
IQ report appears to be showing old
violations against ALREADY RELEASED 2.1.6
says because security violations are
involved, the ODL Security group needs
would like to release Plastic 2.1.7. It has
improvements and fixes violations in 3rd
has been languishing and holding up the next
would like a release process that understands
when “the horse has left the barn” and that
thinks it is a good thing when a new release
fixes vulnerabilities in an old release.
I understand the concerns on the delay in releasing
Plastic, please find my response below.
1. The policy violations are security issues outside
the scope of LF/RE's to determine if they can be
2. The policy violations showing up on stage
repositories is a "feature" and not a "bug", and a
proactive way to ensure these violations are going to
be addressed early on before a release.
3. The violations seen recently in plastic is a
result of updating the "Nexus platform plugin", which
is working as expected and not a result of any to
Nexus repository level setting.
4. It's seldom up to LF or the PTL's to waive IQ
policy violations, waivers can only come from the ODL
security team as approved by the TSC.
The concerning thing here for me is LF deployed a new
release process requiring someone or group of people to
analyse and provide a security waiver to projects before
allowing the project to be released and actively blocks the
project from doing so. While the goal of this process might
be fine and proactive the way LF decided to unleash this to
the world is not.
The community was not informed of the new process, nor
has there been any communication to the communitiy to
setup a process for providing security waivers to projects
(if there has I apologies as I have not seen it and would
welcome someone to correct me otherwise). The problem is
today there is no way for a PTL to have this security waiver
I'm not sure how LF can justify implementing a new
"feature" without first implementing any processes around to
support the feature with the community, then seemingly
telling the community it is their problem to handle it.
Join TSC@lists.opendaylight.org to automatically receive all group messages.