Falcon Update April 2024 #114
Conversation
|
Thank you @dstebila @baentsch ! @baentsch Could you merge open-quantum-safe/liboqs#1735 ? |
Just tried rebase. DCO failed there too :-( |
DCO is part of the OQS Technical Charter section 7.b.ii, so we agreed to it in principle when we moved the project in to the LF. There wasn't a discussion about an explicit timeline on when to activate, so it seems to have been activated when Ry had some time to work through onboarding our various repositories. When he turned it on for liboqs, I did ask him to turn it back from a hard-fail to a soft-fail to give us a chance to adjust to the new workflow, but I don't think I asked for that soft-fail on all our repositories. |
I guess in the future, if we need to merge upstream commits (e.g., #109 ), then we manually approve sign-off. |
How is this done?
With that you mean that a committer simply adds "-s" to the I still don't quite understand who needs to do what in which case. It may be that I'm too slow understanding but it also may be that some documentation on this LF process would help. |
Many, many questions on this:
|
I found the Checks page says
Yes
No idea... |
"Good" in the sense that it's not just me scratching my head... |
Some of the Charter changes you requested were made, some were not; I don't recall all of them off the top of my head. The OQS Technical Charter can be revised, so if there is something in the Charter that you would like to be changed at this point, then it can be raised as an agenda item with the TSC.
This happened. At my request, Ry sent an email to the oqs-tsc mailing list on March 12 announcing this planned change with some links to documentation explaining what the DCO change is and how to use it.
I am not sure exactly what 'TSC-approved process' means in this context. It could mean that -- while the charter requires the project to use DCO -- the TSC has discretion on the specific mechanism used to implement the collection of DCO sign-offs. I'm not sure I see any value in trying to come up with another mechanism, the Charter does let the TSC take this on if we think it worthwhile.
I've gone back in my email thread, and it appears I was mistaken when I said that my soft-fail request was about liboqs specifically. Ry's email of March 12 says that he had enabled DCO checks in the CI, but turned off the branch protection rules to mandate that for the time being -- and this was not limited to liboqs, as far as I know. The closing line of his March 12 email is "I will work with the community to enable this on all repos in the next few weeks.". |
|
Thanks for the pointers to an LF mail. Please see PQCA/governance#1 as to the reason for me not subscribing to those mailing lists: If you could help change the LF position towards true openness for everyone --beyond LF members and people willing to bind themselves to the LF t's and c's-- that'd be great: Some "highlights" of what subscribers to the mailing list agree to:
Back to the issue: Scouring the (currently available information) at https://lists.pqca.org/g/oqs-tsc/topic/104870284#9, it seems committers really only need to set "-s" in commit without further thought. Not sure what this buys us (except headaches when its forgotten). |
From my point of view, this issue is resolved: the mailing list archives are publicly available, and the LF team has said they will keep it that way. I have no plans to take any further action on this front. |
If this isn't sufficient from your perspective, one option would be to introduce a TSC motion to amend the OQS charter to include something like "The TSC shall maintain a mailing list whose archives are publicly available.". I think this is within the remit of OQS (rather than having to rely on a policy change from LF or PQCA) and I think is a reasonable thing for an open source project to include in its charter. This would codify that it is the TSC's desire to have mailing lists treated in this way, and would give direction to a future version of the TSC in the event that the service provider Groups.io, or LF, or some other party attempts to change the visibility of archives on lists.pqca.org. |
|
And on the matter of terms and conditions. The project already uses many third party services from corporations -- Github, Docker, CircleCI, AppVeyor, Travis, AWS -- which all have their own T&Cs, and which participants in the project have agreed to when they signed up for accounts at those various services. I haven't checked all of them, but Github at least has very similar indemnification and change-of-terms clauses as the Groups.io T&C's that you quoted above. Part of the value of being in an umbrella organization is that we can rely on the larger umbrella organization to have the expertise and time to review those matters when selecting service providers, freeing up time for the technical community to focus on technical matters. I don't have the time or expertise to do that for every service we use, and I am willing to rely on them to do so until there's an indication of a problem developing. |
That's a very good suggestion. Thanks! I have a nagging suspicion how this will turn out ("LF cannot do this as other LF projects then would also want this") but let's give it a try. |
That's disappointing, but I can understand that changing LF policies is not the reason you have joined LinuxFoundation. In my eyes, LF very clearly does not commit to openness by the way the legal text is written: This whole discussion would be moot if @hartm would simply be able to point to such LF committment. He does not, so it most likely does not exist, but all statements attributed to LF above are stated to be
Finally, I can understand your sentiment
but it touches on the core problem: LF checks things to suit its members, not the wider OSS community. You are member of LF, I am not. Thus, LF helps you but has no interest to protect my interests (or those of anyone else outside of LF). Economically understandable -- why should LF help outsiders? But so the question goes in reverse: Why should outsiders help LF? I think the answer becomes clearer and clearer by the day (tagging @thb-sb fyi). |
|
A couple of things: DCO is important because it protects open source code from malicious contributions or contributions where someone is trying to "sneak" their IP or licensed code into an open source project. There is actually a whole wikipedia article on why the LF has a DCO process; you might find it interesting to read. Every open source project that is being used in production needs to have a DCO sign-off or some analogue like a CLA. Personally, I am in favor of a one-time CLA sign-off that contributors would sign that would be associated with their LFID, but this has not been implemented yet as it would require links between LFIDs and github accounts and would need more back-end software development from the LFX platform. |
This should be fine. Requiring that all email lists in the PQCA be public is not fine (security lists, budget discussion lists, code of conduct reporting lists, etc. need to be private), and attempting to specify all of the things that shouldn't be public is going to be a difficult exercise. But if you want to require that the TSC list is open and public in perpetuity, I don't expect that to be a problem (although I will need to check with legal to be 100% sure). So feel free to propose it and then we can go get legal approval. |
The LF is always interested in helping valuable contributors, which you are. If you look across other foundations, we frequently help contributors that aren't associated with members, like those working on this project. |
|
@hartm, would you like us to first pass a motion at the OQS TSC proposing an amendment to the OQS Technical Charter, and then get the legal approval, or first get the legal approval and then make a motion to amend the Charter. For a motion, my initial thought is to add a section 2.h to the OQS Technical Charter reading "The TSC shall maintain a mailing list whose archives are publicly available." |
|
The best way to go is probably to ask legal for the precise text we should use. I'll go ahead and ask Scott. |
I have to say that I couldn't agree more with this. This is the first time I've worked with LF, but certainly not the first time I've contributed to an OSS community, and this is how I see OSS communities: they are often made up of people willing to devote some of their free time to projects that can benefit everyone. Correct me if I'm wrong, but OQS was kind of a hobby/lab/playground in the first place, for trying out things around a (not so new anymore) subject (PQC). Today, I can't say I still have the same feeling, even if my willingness to contribute persists. This issue with the openness of our ML archives is one of the blockers to that feeling I've attempted to describe above. I'm sure folks at LF have no intention of behaving this way, but it gives me the impression that an external third party is taking over our beloved playground, and is trying to control how we contribute, how we communicate, and what might/should/must get archived. Said differently: now we have to think of DCO, signing stuff (not talking about cryptographic signatures here), we have to wonder "can I use this mailing list? Who controls it? Is it OQS? Are these the people I met at this conference last year? I'm not sure". -t |
It kinda-sorta was that at the start but took on more features of trying to be reliable and useful for more than just "play" -- that at least was my intention/feeling the last four years I contributed seriously. This somewhat more real-world usage goal also was the reason for me doing
+1. Also touches upon open-quantum-safe/tsc#1 -- for which NO feedback was received by any employee of LF or one of the LF companies: This leads me to think we may want to keep OQS indeed as a playground and let LF shape PQ Code package as they please. This at least is the reason why I'm staying away from that as far as I can (apologies to @praveksharma for not helping with open-quantum-safe/liboqs#1745 for this very reason). It would mean we'd need to push back hard against anything LF can't document generating real value for OQS users, though.
Exactly my thoughts. LF slaps on their contracts (leading to discussions such as this), procedures and tooling, sometimes without explanation or documentation most likely to protect its corporate sponsors. But the approach taken doesn't exactly generate sympathy -- particularly by people not paid a "compensation" (in the true meaning of the word) to cope with this "legalese" (stronger word deleted :-) and/or folks not affiliated with LF (which still is a significant majority in the bigger picture :-).
That's great to hear and a relief & encouragement for me to not drop the ball immediately and give the LF folks (and employees of LF companies) time to prove their willingness and ability to contribute something of technical value and not just "process" and changing pretty completely the notion of openness from how I understood it. And apologies from my side for having turned so "tardy" during the past few months that it became clear LF takes over the project: It's simply hard to maintain motivation to work for free for multi-billion-$-profit companies... Their main goal is to make more money, e.g., by protecting their IP (rf. DCO) or keeping the OSS community guessing where they focus their investments (rf. "budget discussion" remark here) while mine (and I think the general OSS community's contributing to OQS) was to do something sensible for everyone (beyond corporate America that LF pretty exclusively seems to cater to). |
Nice words, as always, thanks, @hartm . Could you please remind me where LF acted accordingly during the last 12 months prior to and since the OQS take over? I remember many conversations, contract proposals, etc. where my proposals or requests for help were nixed but not too many where one was granted. But again, I'm old and forget many things, except the negative ones, as most people :-( My feeling was always that LF doesn't know how to deal with independent contributors, let alone maintainers, and hence, prefers to sideline them. May it be possible for you to tag here a non-LF associated maintainer in another LF project to chime in to this discussion to help change this impression? |
|
I asked LF legal about the mailing list issue and got back the following response:
Note that the project charter text can be found here, among other places. The "Series Manager" is the Linux Foundation's legal team, and you can send mail to them at [email protected]. So, as it was explained to me, keeping core email lists open would definitely fall under this clause. If this ever were not the case, the project would be in violation of its charter and you could (and should!) contact the email above to fix this. I hope this clears things up, and I hope this means that things are acceptable to you with respect to the email lists. |
|
Thanks for the "background check" and explanations.
So would this be a fair summary with few(er) words: "If LF ever removes open access, one can complain to LF about this." ? |
|
On a more philosophical note: at least in my understanding, the main reason that OQS was moved to the LF was so that code from OQS could confidently be used in real-world, production deployments. The goal of all of this extra stuff that the LF requires is not to protect member companies as much as end users of the software.
This is wonderful, and we want to ensure that there is space to "play" in OQS/PQCA. But we also have to acknowledge that if we want to build production-grade software, we can't entirely take an attitude of "here is our canvas, feel free to paint whatever you want".
We always try to make code contributions as frictionless and as easy as possible. Unfortunately, we have to deal with the reality of the world: that there are bad actors and we need safeguards against them. It is an unfortunate fact of software development that if you want to use code in any kind of deployment, it needs to be appropriately legally protected, or otherwise any users/deployers could face legal action.
The mailing list(s) is totally open and public today; Michael's points were focused on ensuring it stayed that way.
I highlighted the need for DCO above:
You may think that it is unfortunate, but it is necessary if you want people to be able to confidently use your code.
The goal of all of this stuff is to protect users of code, not corporate members (although they may also benefit from being users of the code). Developers that wish to see their code used also benefit from these things.
People generally trust the LF, and it's typically because of our track record. We hope that you all will come around in time.
There are a couple of misconceptions here that I want to be sure are clarified.
In summary, the DCO exists to protect users of the code from companies that may hold IP related to the code. I hope this is clear.
This kind of thing may seem unusual if you haven't worked in the nonprofit space before, but it is standard practice.
If you want to see your code used in practice by many, then these practices we are recommending are unfortunately necessary. You shouldn't use code that hasn't been audited and cleared from a security perspective in production, and you also shouldn't use code that isn't cleared from a legal perspective in production. People in this project are generally much more familiar with the former than the latter, but that doesn't mean that the latter isn't important too. I hope all of this made sense. If you've made it this far, thanks for reading! |
You can view it as the ultimate "talk to the manager". If someone at the LF or in the community removes open access, then you can report it to people at the very top of the LF and they will get it fixed. I have never seen this provision get used with respect to LF staff; when folks have issues with openness, it has typically been with things like company employees (usually new to open source and not knowing any better) keeping important communications about an open project internal; if this happens, you should contact us. These things are usually fixed quickly. |
|
Tagging @dstebila and @baentsch I have the following two questions regarding OQS-BoringSSL and hope they will be addressed at the next TSC meeting:
Due to time constraints, I regret that I'm unable to participate in TSC meetings, but I expect to attend in May. Thank you! |
AFAIK, BoringSSL is not controlled by LinuxFoundation and therefore I do not see how a fork of it should be governed by LF rules. I'd therefore think it'd be logical to consider such exception automatically granted for such forks. But @hartm's lawyers most likely will have a comment on this...
The way I see LF's DCO mechanism work is that it is not requiring a real cryptographic signature or actual CLA on file but just requires presence of some text hinting at the author doing the merge. So, would it be conceivable you'd simply add this text (also created by the
Personally, I'd completely exempt |
I don't want to do this because those commits are not created and authored by me. An exception made for OQS-BoringSSL will be the best. |
I've created open-quantum-safe/tsc#13 to track this issue. |
|
With the passing of open-quantum-safe/tsc#17, we've approved the license exemption for BoringSSL and we can continue contributing as we have been under the repository's existing license. |
This update is compatible with liboqs 0.10.0.