toggle quoted messageShow quoted text
Some of our IT/RE management team are out of the office today so we have not yet completed a proper investigation. Please give us until end of day Monday to respond.
Sorry for the delay.
Technical Program Manager / Community Architect
IRC - CaseyLF
WeChat - okaru6
On Fri, Mar 6, 2020 at 3:47 PM Luis Gomez <ecelgp@...
Well, that is what LF is investigating now per my understanding but this should not block Allan to use the security team avenue.
On Mar 6, 2020, at 3:26 PM, Jamo Luhrsen <jluhrsen@...
thanks Luis, Abhijit.
Anil, Casey, still wondering about the v2.1.6 vs v2.1.7 weirdness
that keeps getting
On 3/6/20 3:18 PM, Abhijit Kumbhare
- Casey Cain to work with LF
IT to address communications to the community regarding
security issues. 06 Mar 2020
- Casey Cain to follow up
with Allan Clarke Thanh Ha and the community
on Plastic security issues 06 Mar 2020
On Fri, Mar 6, 2020 at 3:03 PM
Luis Gomez <ecelgp@...
Few outcomes from yesterday TSC call (at least for me):
1) Thanh will open a ticket to LF to work on a new feature to
notify users upfront if there is a security problem in the
staging build. I think Allan was waiting long time to get this
2) LF will look at the current Nexus IQ problem of reporting
old SW security issues in new SW scans.
3) In the situations where it is believed Nexus IQ is not
doing the right thing (like this one), the impacted
project/person will rise a mail to ODL security team (security@...)
with all the details. The ODL security will analyze the
problem and if it turns out to be a tool problem, the security
team will provide an immediate waiver. If there is a real sec
issue, the project/person will have to fix or ask a waiver to
4) ODL community needs more and better communication on how
things work and change in LF.
> On Mar 6, 2020, at 10:37 AM, JamO Luhrsen <jluhrsen@...> wrote:
> I missed the TSC meeting last night. Can someone recap
over email what came of
> this? I see one note in the minutes that Casey indicated
that no change has
> occurred in the policy regarding security violations, but
that doesn't seem
> 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 feels like
> something changed...
> Also, nobody is answering why the nexus IQ reports are
failing v2.1.7 with
> logs and messages about v2.1.6. Allan has mentioned that
multiple times and
> 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@...>
>> I 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.
>> LF is not allowing newer release of Plastic 2.1.7
that fixes 3rd party vulnerabilities already in 2.1.6 release.
>> LF wants ODL after-the-fact approval for Plastic
2.1.6 that is already publicly available.
>> Both LF tooling (Nexus IQ) and vulnerability process
>> Here is the sequence of events AFAIKT:
>> • Plastic 2.1.6 released (months ago)
>> • LF silently changes release process to require
Nexus IQ passing (no docs, no links to help PTLs BTW)
>> • Plastic 2.1.7 candidate build successful but
not available for testing
>> • LF helpdesk says Nexus IQ violations making
>> • (Older version of Guava and Groovy have
exposure on features not used by Plastic)
>> • LF finally gets accounts and links fixed so
Nexus IQ reports are available to PTL
>> • New version of Plastic 2.1.7 candidate build
>> • Build still not available due to “violations”
>> • Nexus IQ report is all screwed up in the UI,
mixing 2.1.6 and 2.1.7 up, mislabeling, clearly buggy
>> • Nexus IQ report appears to be showing old
violations against ALREADY RELEASED 2.1.6
>> • LF says because security violations are
involved, the ODL Security group needs waivers.
>> I would like to release Plastic 2.1.7. It has
improvements and fixes violations in 3rd party libraries.
>> It has been languishing and holding up the next major
>> I 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
>> Allan Clarke
>> Plastic PTL
>> Greetings Allan:
>> 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 waived.
>> 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 approved.
>> 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.