SLSA Specifications Meeting  ## Metadata - Author: [[OpenSSF]] - Full Title: SLSA Specifications Meeting - Category: #articles - Document Note: --- tags: - #educationSIG - #opensource - #linuxfoundation Author: Education SIG Members Source: Education SIG Meeting (YouTube Transcript, July 12, 2023) Reference: https://www.youtube.com/watch?v=nH-tH9YYUkg date created: 2025-08-25 21:55 --- # Title: Education SIG Call — July 12, 2023 ## Table of Contents: - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📖 References](#-references) - [🗣️ Paraphrase](#-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🔍 DARVO Analysis](#-darvo-analysis) - [🔍 SEO Evaluation](#-seo-evaluation) - [🎯 Conclusion](#-conclusion) --- ## 📝 Summary: This call centered on the **mobilization plan audit**, stalled **funding approvals**, and the need to align with the Linux Foundation’s **five-year roadmap**. Members discussed **maintainer fatigue**, the pilot of **project-authored courses**, and the CNCF’s **four new express learning modules**. They emphasized workshops (like **Code-to-Cloud Security**) and conference outreach (Bilbao, KubeCon, Supply Chain Security Con) as strategies to spread education beyond the OSS bubble. Calls for content variety (video intros) and better course delivery systems rounded out the session. --- ## 📖 Main Content: The conversation began with informal talk about time zones and balancing work with childcare, blending humor with lived realities of OSS contributors. The first formal agenda item addressed **funding delays** for the mobilization plan. Approval was on hold, with Omkar expected to include initiatives in the **2024 budget cycle**. Members stressed getting projects positioned early for financial backing. A key update highlighted the **“Newbie course”**, currently internal, with plans to adapt it for public use. Content audits and updates were needed, with one member noting they had already submitted **40 pages of feedback**. The LF is piloting a **course-authoring platform**, enabling projects to design and publish their own content. This initiative was tied to concerns about **maintainer fatigue** and the need to lower barriers for educational contribution. The CNCF **Secure Cloud Native Security Slam** was expanding its scope, with four **express learning courses** due: - S-BOMs in provenance automation - OpenSSF Scorecard - Security self-assessments - Supply chain security documentation Members discussed adding **short video intros** to courses to increase engagement without creating unmaintainable video-heavy content. Later, they examined the success of workshops like **Code-to-Cloud Security**, arguing that hands-on learning is more effective for developers. Strategic outreach to **non-OSS events** was proposed as critical to broaden impact. Finally, participants shared plans for Bilbao and KubeCon, underlining the importance of **getting outside the bubble**. --- ### 🗒️ Notes - [00:03](https://www.youtube.com/watch?v=nH-tH9YYUkg&t=3) Informal greetings → balancing kids vs. engineers; humorous laptop story. - [06:40](https://www.youtube.com/watch?v=nH-tH9YYUkg&t=400) Mobilization plan audited; funding frozen. 2024 budget key opportunity. - [09:50](https://www.youtube.com/watch?v=nH-tH9YYUkg&t=590) “Newbie course” exists but is **internal**. Plan to audit + release publicly. - [11:21](https://www.youtube.com/watch?v=nH-tH9YYUkg&t=681) LF piloting **project-authored courses**; linked to Omkar’s education priorities. - [16:19](https://www.youtube.com/watch?v=nH-tH9YYUkg&t=979) CNCF expanding **Secure Slam** → 4 express learning modules. - [20:39](https://www.youtube.com/watch?v=nH-tH9YYUkg&t=1239) Security slab → gap-driven education. Maintain pragmatic tools. - [24:58](https://www.youtube.com/watch?v=nH-tH9YYUkg&t=1498) Add **video intros** to courses → break monotony, avoid video bloat. - [29:24](https://www.youtube.com/watch?v=nH-tH9YYUkg&t=1764) Workshops like **Code-to-Cloud Security** → highly effective hands-on learning. - [33:42](https://www.youtube.com/watch?v=nH-tH9YYUkg&t=2022) Bilbao + KubeCon outreach → expand education outside OSS community. --- ## 📖 References: - Linux Foundation Education SIG notes - CNCF Secure Slam documentation - OpenSSF Scorecard resources - LF course catalog --- ## 🗣️ Paraphrase: 1. *Original*: “Approval right now is on hold. No one has jumped up to hand us a pile of money.” **Paraphrase**: Funding approval has stalled, and there is no immediate influx of financial support. 2. *Original*: “We need to invest some time in getting content under the hands of developers more.” **Paraphrase**: The priority should shift from creating more content to ensuring existing material actually reaches and benefits developers. --- ## 📰 Newsletter: 🎓 **Education SIG Update: Training Without Funding?** The July 12 Education SIG call wrestled with **budget freezes**, but contributors kept momentum alive. Updates included a **pilot platform for project-authored courses**, a plan to adapt the **internal “Newbie course”** for the public, and CNCF’s upcoming **four express learning modules** (S-BOMs, Scorecard, self-assessments, supply chain docs). Workshops like **Code-to-Cloud Security** are proving the value of hands-on training, and with Bilbao + KubeCon on the horizon, members urged everyone to **get outside the bubble** and share open source education more broadly. 👉 Resources: [Education SIG video](https://www.youtube.com/watch?v=nH-tH9YYUkg) --- ## ✅ Action Items: - Align OSS education efforts with **2024 LF budget cycle**. - Audit and publish the **Newbie course**. - Support **project-authored course platform** pilots. - Deliver CNCF **express learning modules** by September. - Add **video intros** to course sections. - Expand outreach via **workshops and conferences**. --- ## 🧪 Hypotheses: - H1: Express learning modules improve contributor skill adoption faster than traditional courses. - H2: Workshops yield higher retention of secure practices than video lectures. - H3: Strategic outreach at non-OSS conferences diversifies contributor pipelines. ### 📊 Methodology: - Survey contributors pre/post module use. - Compare adoption rates between workshop-trained vs. lecture-trained groups. - Track contributor demographics across event outreach. ### ❓ Questions: - How do we reduce **maintainer fatigue** while expanding education? - What’s the best mix of **free vs. funded initiatives**? - How sustainable are project-authored courses without strong QA? ### 🔮 Future Research: - Longitudinal study of workshop vs. course learning. - Impact of outreach on **geographic and cultural diversity**. - Evaluation of hybrid models (workshop + online courses). ### 💡 Implications: - Can shape **LF budget priorities**. - Offers **replicable models** for other open-source orgs. - Provides pathways to **reduce contributor burnout**. --- ## 🧠 Learning Styles Assessment: - **Visual**: Weak (few diagrams) → add infographics. - **Aural**: Absent → offer audio summaries. - **Verbal**: Strong (detailed discussion, analogies). - **Kinesthetic**: Strong (workshops). - **Logical**: Moderate (structured, lacks data models). - **Social**: Present (collaborative planning). - **Solitary**: Weak (few reflection prompts). - **Naturalistic**: Absent. Readability: ~12th grade level. --- ## 📊 Accessibility Assessment: - No mention of screen reader compatibility. - Recommend: transcripts, alt-text, semantic HTML. - Keyboard navigation: not covered. - Course platform: needs better lab load speeds. --- ## 🌍 DEIB Assessment: - Inclusive language: mostly neutral, but Western-centric. - Cultural scope: limited to US/EU. - Neurodiver - Summary: The SLSA Specifications Meeting held on July 10, 2023, discussed version management and release notes for minor updates. The participants emphasized the importance of clarity in documentation and the need to associate changes with specific versions. Overall, the meeting aimed to improve the community's understanding of versioning and specification updates. - URL: https://www.youtube.com/watch?v=ZJcTSK83CIs&ab_channel=OpenSSF hey everyone thanks for joining us yes we'll just give it another minute or soput Focus to roll in and then we can getstartedum in the meantime Melba's dropped alink to our kind of agenda minutesdocument in the chat so if you could um send me your name there as anattendee and if you've got any topicsplease feel free to add them hey everyone umthank you everyone who already startedthe meeting notesum and registered attendanceuh if you haven't already pleaseremember to do so I'll paste the link in the chat for convenienceuh oh we're having a good crowd todayumandumfirst we want to welcome any new memberswho'd like to say hiif we have anyI don't think I reckon I think Irecognize it was a run okay wellum if you want to try and go go for itwe'd love to say hiumJoshua I think you have the first uhissuetopicyes we talked about this a bit on someof the issue comments uh earlier todaybutum there's an issue open number 900about uh releasing a 1.1 releaseum and some related discussion on gr-892 which is aboutumclarifying that the um the specificationtext is kind of the authoritativedefinition of the spec and the differentschema formats are informativeumI think we've come to a consensus thatwe should do a version bump because eventhough the the specification textsarguably haven't changedum but we are informing the reader then assumption that they may have made mayneed to be reevaluated right so I thinkthere's a strong reason to have a 1.1release uh and I wanted tobring that to the group and discusswhether there are other things we shouldinclude I would advocate for doing therelease relatively quicklyum and I also wanted to discuss the umbuild system changes that were salsaproposal number six and whether weshould umwait for those before we we do anotherrelease effectively soum sorry quite a lot of uh points therebut um Mark who put your hand raisedyeah just to clarify the my comment on892 that's the conical one thingum was about a patch release as opposedto a minor releaseum I'm not saying that we shouldn't do aminor release but I I literally meant just calling it 1.0.1 thatyeah what my comment wasgreat clarification because I couldn'tfind I seem to remember us talking aboutFolsom for versioning in the past anddeciding that patch releases didn't makesense because we were going to not wantto do that for everyum clarification to the spec and we onlywanted to bump version when we weremakingum like a a feature change for one of thebest um because that's the center thecenter terminology and I kind ofpersonally went back and forth on wasthis a feature change or not and I fellon the my position I kind of concludedwas that because this may cause a readerto reinterpret thingsthat we shouldum signal that somehow and the versionnumbers the best way we have to sign up um but I yeah I I was thinking minorrather than patch because I thought we'druled out patchesyeah yeah I get am I sorry for myconfusing comment I meant literally ifwe choose not to do a minor release andwe add like one every time wewe we are through exclamation issue forthis rather than like a random commentburied in one of the pull requests uhevery time we do now that we have the umor we soon we'll have I guess we'retaking that um the commit convention for like weclassify commit or pull requests iseither likecontent or editorial or blah blah blahanything with a Content which is likethe most highest Priority Oneumwould require arelease notesum and if we have any such changes wherewe change to something after releaseumif we're already doing that would it beworthwhile just calling it a patch release in theuh in the notes Maybe not maybe thatwould just be confusing or not worth thetroubleum just like what is the convention forlike we did maybe moving a date wouldactually probably be more useful than uhactually probably a date is more usefulbut either way like some sort ofsomething so people could follow alonglike oh I looked at 1.0 last time and itsaid this it doesn't require I don'tremember it saying this and then we havesome place to lookum I guess that isum slightly orthogonal tooshould we not do that in this case andshould we bundle them up into a minorrelease yeah I think that's I'myeah I think it is somewhere related andmaybe we need tocapture this discussion in our uhconventional commits relateddocumentation but I had assumedthat spec content would mean a minor or major version number increment would berequired and the spec editorial wereeffectively patch releases and that wehad uh kind of agreed in the past not tomake practical uses butyeah I can see an argument for wantingto be able toum check ones outside sanity did I am Imisremembering what I read uh but Ithink like we have a public gitrepository and we try to be fairlydetailed about encouraging folks to have good pull requests messages and thingsso I'm not sure that we need to go totheextent ofumcreating a change log for all of thespec editorial and non-spec kind ofpatch changesthat's yeah mymy thoughts I'd love to have someone uhcommentary otherwise if they feelstrongly about it ChrisumJoshua's understanding matches mine thatcontent would be major minor andeditorial is effectively patched but wedon't have patch releasesI mean we can add them it's easy enoughjustuh that's just a a non-spec changeI said yeah I hadokay I had not assumed that so we should be explicit about thatumso then uh okay any other thoughts I'dbe interested to hear other thoughts toogood I think we agreedno I think one of the reasons that patchrelease doesn't necessarily make senseis that I don't think we want to keeplike uh published versions of the specfor each patch incrementum at which point the number to be clear Iwas not suggesting that we'd actuallypublish you'd be able to easily viewversion and all the patch releaseit would be like thatum python docs where like you could viewevery minor release but it's always thelatest patch of thatumso anyway that I'm not saying I'm notnecessarily trying to argue for that butjust that was kind of myyeah Andrew sorry I'm trying to take this my car soumI apologize for the noise I feel likeif there's any spec changes whether it'scontent or editorialit warrants a change log release notesbutI would say that for editorial it you itwouldn't it shouldn't require a versionchange because there's nothing that'sactually changingum so not until there's content should a version like a the minor version atleast be bumpedum but make sure that if there's anychanges to the specification pages thatthat change is made awareumso that it can be tracked in order tohelp that discovery of oh that theremight be Clarity in this playdisplacement clarityand Andrew are you advocating for uh that being an explosive content onthe website rather than just uh getcommit blog that existscan you repeat thatare you suggesting that the git logs areinsufficient for that purposeget logs might be helpful butI I think that umsome way of being able to surface itthrough salsa.dev would be beneficial and the release notes or a changelogwould be would be helpful so if if youhad aum editorial change that is introducedyou can put it on there but not tied toa version and then once there's a minorversion bumpuh then it can be associated with aversion but until there's that minorversion bump it would be associated withwhatever latest iscool I think that makes sense yeah I I agree I think the umit would I actually hadn't been thinkingabout putting editorial stuff in thechangelog but I I think you're rightbecause like if you what we considereditorial about is kind of ablurry line and so if you go to readsomething it's like oh it doesn't readlike I have it's the first if if it'sclearer to readers that they can lookinto the change log and see changes thatmight make it easier [Music]umand uhI don't we could talk about exactly howbest to represent that but I do thinksomething that's on the website eitheron a single page or like the bottom ofeach pageum ideally autogen well I'm not sureideallythere's nice aspects to auto-generatingit where like it would be maybe just thetitle of every pull request like if wehave good titles pull requests if wehave titles and then a link to the pullrequest where you can see the actual diffum that might be nice and because if wecontinue to follow this conventionalcommits uh which I think is great by thewayumthen we could filter out and only dothings that are you know editorial orhigherum and that way you filter that noisebecause I think the commit log in GitHubin the past certainly was unreadable andnow should be cleaning up now that we'rewith doing the squash but um it's still kind of hard to read andso having it on the website I think it'smuch more user friendly I think it's acleaner kind of separation of Duty so tospeak with the git Hub project and getbeing the uh you know the implementationpiece that we focus on but then if userssee a change logo on the website uh thatkind of matches that being the userpresentation layer and sure it mightbounce them through to get hope to see the diff if they want to see exactlywhat changed but uh it feels like aclearer boundary between the tool andthe output this wayso so to clarify I thinkwhat we're saying is if if I don't knowif anyone has read the conventionalcommits can thing but the standard termsare I think feetshort for a feature and anything thatthat is like a minor release I think is that true and then they also have bugwhich I think in our case would beeditorial I think it kind of mapssomewhat well to editorial and then youcould have other stuff and there's likeconventional commits talks about kind ofauto-generating things but and somethingkind of ohthere's likeyou know like this is just a doc it'snot like hard-coded but um I think wecould have something likeyou know every editorial and above gets a changelog entryand everything which is equivalent tomaybe a patch release and everythingthat's content or above requires a minorrelease and we'll have to figure out howwe do the version management and thatcomes back to the next bulletum and then they have some way of sayinga breaking change which would require amajor releaseumbut we haven't gotten there yet just just a question if we do minorreleases do we have that I remember whenwe did the drafts of the 1-0 there weretwo weeks uh latency on having thechange inand do do we have that for minorities oruh or not[Music]I think that's a good question uhhonestly I had not anticipated during that I was thinking of um that likereview periodbeing more for the major releases butI'm not opposed to doing them for minoryeah I think it would make sense if toto be more agile in that way not to waiteach time for two weeks if we have topush stuff but I don't know what ourstart the statues are for what's upa lot of the desire for having thattwo-week period initially is because uh 1.0was quite a significant change fromum the initial release where a lot of uhattention had been on the project youknow people were still talking aboutum some of the requirements from0.1 uh even after we had removed themfrom the kind of draft releases of 1.0so we wanted to have aum a period where we tried to get some of those folks to come back and look atthe spec and provide feedback to makesure that the major changes we had madewere still going to be useful for thembutyeah understoodit's also in the community specificationlicenseum the two-week thing isum as far as I understand for patentslikeum the contributors Grant a royalty freeblah blah blah something or other four released versions or I think what's itcalledproved versions or something like thatum but not necessarily for intermediatedraft versionsum but it seems like it's really writtenaround like there's a spec on like anietf spec that's written once and maybeit's written you know an update but it'slike a big heavyweight like not like arolling release like we have so I I feellike it's not actually a great fitum I think we should bring this up with umuh whoever in Linux Foundationumto make sure thatyou know we're following I want to makesure that we're following the right yeahwe're doing the right thing from thelicense perspectiveyeah I think the community specificationlicenseis the default license in the open ssffor non-software projectsum so we can certainly uh yeahconnect back with uh uh open a surfpossibly via the attacktoevaluateum the fit and see if that's still theright the Right Way Forwardso in we could talk about like themechanics of exactly how we do itum I think that's easy to do offline to have a proposal we could iterate on itumone thing that I think it's worthdiscussing now is likefor minor releases howhow big should they be and how frequentshould they be so the things that we'vewe're talking about to possibly includein a releaselike this one is likejust clarifying was it which isauthoritative it's not really a majorchange um the VSA one is changing some requiredfields to optional but it's not a majorchangeum I don't know if there were other onesum and ultimately with the versionnumbers we're just we're using this as acommunication mechanism right because wewantthere's kind of a balance uh anythoughts on that like is itbetter to just not do the minor releaseto not have noise or is it better to domore minor releases to have a clear kindof protocol for when when things breaking changes happenso I can jump in and just yeah reiteratethat I think it's better to have thecommunication mechanism and semanticversioning convention is if theumif there's not a breaking like if you'reintroducing new functionality but it'sin a Backward Compatible way that's whenyou get the minor version numberincrement and that feels like what we'redoing certainly With The Changes we'vediscussed hereumand because they are not backwards incompatible if someone has implementedsalsa one and we've then pushed salsa1.1 and they choose not to implement itthat should be okayumso I think yeah I I don't think I knowmy preference would be to to do theminor versionum numbers just to signify uh that we'vemade somelike non-trivial changes season more sales ideasuh Chrisuh I'm also in favor of of doing theminor release relatively soon I thinkthe question is is there anything comingup that we would want to batch into itanddoes it make sense to say we won't dominor releases more than like I don'tknow once a month months a quarter thatsort of thing because you you I wonder if having minor versionshaving minor versions doesn't createnoise having them unexpectedly createsnoise perhapsyeah I think uh trying to batch them upum so that we're already making themperiodically uh does make a lot of senseand I think even quarterlyumwould be you know kind of sufficient like none of the changes that we'remaking right now areshattering they're just nice for themost part they're nice to have so sayingwe'll we'll do that a quarter afterum or we'll do that within the quarterafter the initial one that they'rereleasing then we'll not make anothersimilar release for another quarter Ican see the appeal in that I'm fine with that most quarterlyso umin terms offeel free to steal the discussion ifyour wife you want to talk aboutsomething elseumwhen satyanu is is on leaveum Tiana is the one who wrote the didyou link to it from hereum the branch strategy thingumoriginally in this meeting we had talkedabout like developing on a branch andthen building that into a website tianulooked into it kind of looked at he didthe proposalum and that wouldthere's pros and consum oh yeah thanks Joshuaumit would make contributing a little bitharder because you have to like submitto the branch and then the building I'mnot too worried about the implementationbecause like maintainers could justwrite that and only a couple people needto understand itum but I'm more worried about thecontribution process and like thebarriers to entryumand the original proposal was that wedevelop on a branch and then merge itinto like main or something like that um and then there was concerns aboutlike complexity there and so where welanded was we'll just build on MainI'm sorry we just contribute on Maindiversion directories like we have nowand thenumuh you could kind of use um some sort ofget something rather subtree orsomething like that uh to to build likethe actualkind of infer the real history from themerge thing which is kind of weirdum but that was assuming that we're notgoing to have very many like of these kind ofpatch changesum but we already have like three inFlight I think two or three in flightwhere we would have to in order to dothat we'd have to create the versiondirectoryum and so I wonder if we shouldany thoughts there and like what'sa good way for doing version managementhere yeah Joshuaum when I skimmed The Proposal earlywhile I was thinking about this uh it talked about having a branch for arelease so I could see you know having Idon't know if it makes sense to put wewe could choose a granularity at whichtopublished versions of respectum and have a branch track of thatversion corinularity and so I think youcould decide[Music]umthat's an option I guess I I'd becurious to hear from others uh who are less involved in the sausage makingand have a bit more of a consumerperspectivewhether there's value inseeing for example all of the minorreleases uh listed on salsa.favorable ornotso yeah if anyone has any thoughts onwhat level of release granularity you'dlike to be able to see through thewebsite but um Andrewsum Andrew you're really unclear towhatever the difference issomeone yeah Andrew you're broken up a lotum I don't think anyone can really hearwhat you're sayingyeah he said he was in his car before somaybe uh there's no signaloh and it looks like he dropped entirelysoI think it's a signal problem um yeah hopefully we'll get him backso I think is if I say Mark your concernis having a bunch of uh directories inthe top level for each minor release forexampleyeah I keep like basically like it's oneof those things where like you look atwhen you're like oh no that's bad I'mgonna go over here and you're like oh nothat's bad and you can't look then youCircle you just keep going in a circlebecause none of the options look verygood um yeah my concern with the status quois the version directories that likewhen someone wants to contributeum like the VSA one for example or theone that you just sent there the um 892.uh you naturally would do it for thecurrent thing we decide oh no thisrequires a minor version bump and thenwhat do you do then we don't have a onepoint well two things one we don't havea 1.1 directory yet and two we don'thave and and it's not proposed to havelike a latest thing and so in order to see that newversion there's nowhere to view itum which we could do but we need tochange what's currently in The Proposalyeah yeahAndrew are you back nowyeah let me try again right before I gethome there's always a big holeum sowhat what I perceive as being a simplerform and I I'd obviously missed a lot ofconversation but if we just have people contribute towards the default Branchtowards Maine and then we have releasebranchesum then whenever we decide thatwe have reached that quarterly moment ofdoing a minor version bump or orsomething like that then we can justbatch and cherry pick all the relevantcommits to whatever the branch is andthen you'd still use main to trackwhatever the latest isum and so then the the burden wouldn't be on contributors the burden would beon the maintainers toensure that we have appropriate updatesof the versionsum and so you would have uh I think thateven if you have a branch permajor version then once you get to yourquarterly minor or your monthly minorversion just cherish pick everythingoverand update that the the branch tracking that main are tracking that main versionof this firstokay uh maybe what we can I don't knowif it was discussed before but I thinkuh so using main for contributionknowing that most contributions are noton the websites uh or stuff related tothe web but on the spec contents so wekeep the spec thereand I have a special Branch for the for the website there is only one websitethat will list the stuff we want topublish the branch we want to publishbasically so there will be a specialBranch for the website and then mainbranch for uh for amending the specs andthe salsa framework that we branch eachtime we do a really minor or majorand we can decide on the web branchwhich uh stuff we want to publishand we can adjust with time so so I didn'tquite follow you're sayingthere would be oneI'm sorry I didn't quite well you'resaying they're one branch per majorversionI'm sorry no each time we do release wedo branchbut we keep a separate Branch for the website because in the end we haveseveral Branch but we have only onewebsite that will hold all the theprevious stuffso you put a little bit emergencyversion branches are you sayingyeah the web branch will do a checkoutof the branch you need to publishbasically and we can automate thatprobably I don't understanditI would say for Simplicity unless you'replanning on going back and applying Hotpatches to previously released branchesout there then I wouldn't do a branchper release I would just do a tagand then the next time we need to doanother release we're just doing a tag with the next current versionyeah back porting actually is my I guessimplicitly my my concern that like if wehave an editorial changeuhwe've I think probably want that to gowell I guess we could make a decisionlike do we just leave the text as is anddo quarter releases and just batch allthe changes until next quarter release Ithink if we do thatit becomes simple we just have a thing we use tags Auto build it it'sstraightforwardum so thanks for calling this outumI was assuming possibly incorrectly thatwe would want to have some changes golive right away and somehold until the next release so likeanything editorial and Below stylechanges Etc we want them to go out rightaway but then anything with the contenttag which would require patch release we want to like have in some separateholding area and not be live on like saythe 1.0 directory but it is visible onsome like one point x directory and thenthat gets batched but likethese are some cherry picking mergingsomething or other going on but maybemaybe that's too complex yeah Joshua uhI I just wanted to say that mymy assumption matched yours which isthat we would have some changes just golive straight away because they didn'treally impact the umimplementation effectively and that itwould only beumcontent changes I think it's the righttag thatum would be batchedum I'm trying to think whether having abranch per major version would and thenlike tagging the minor version releaseswould helpuhbe a compromise betweenhaving too many directories and being really messy or notum and I'm not sure honestly sounfortunately I'm beginning to think weneed to go back to the drawing board abit with proposal six and experimentwith the different options because it'shard to reason about I'm just updating the meeting notes totry to capture what we're talking aboutand anyone please edit meeting notes ifI'm trying to talk and type at the sametime and I'm horrible at thatumthanks for doing thatum II want to uh I feel like we'veprobably hit the umecological conclusion of thatdescription unless anyone else hasstrong opinions it feels like we areagreeing that we want to make a minorrelease uh a batch minor releaseuh soon for a 1.1 for the changes thatare in flight nowumand that we recognize that we probablyneed to rethink proposal six as aconsequence ofumthis idea of batching minor releases uh once per quarter or sookayumshall we use the remaining time todo issue triageChrisare you okay to leave that one yeah yeahlet's try thatuh sorry uh we we've got uh quite a fewthis time so let's start with891 that's discussion on verifyingpackage names so there's been a lot ofdiscussion on this issue already butI think a rough summary is that they're due to a quirk in the way that npmhandles package names it'sit's possible to install a package andverify its provenance butget thehave the package installed under adifferent name than you expect I knowMark you've been active on this youshould does that sound like a fairsummary actually a lot of us have beenactive on this issue uh Joshua tooChris assuming you're looking at theseissues now do you want to share yourscreenyes uh just a momentI think I would summarize yeah I thinkwe're going to agree with you a summaryof the issueumeffectively you can you can download annpm package to install offline but if you do that uh it's up to the person whodownloaded it to well anyone couldrename the packageum and it'sthe concern is that the package namethat you install might not matchtheum Providence metadata and the name inthe package.json file inside the tarbulb but as I under if I'm followingthings correctly the name of the liketurbo that you install affects theinstall location effectively so you can umgive it a false nameyeah yeah there'sumbasically when in npm and maybe otherecosystemsthe name is there's two different lookthe name is in two places one is theartifact itself contains its own nameandthe tooling that does the package installation gets a name from someexternal Source like the user runningnpm install blahumand some things like npm don't actuallymake sure that they both match and uh ifthey don't matchif it doesn't give an error one will winand so the question isfor the salsa verifier tool which nameshould it be checking againstummy feeling is that well I guess there's the the question about what should thespecification Say and What should thesalsa verifier tool actually doum because that's just oneimplementationmymy feeling is thatthis well I mean because this comes uplike we should the spec it would be goodto have this clear in the spec of likethat this is a thing I wonder if maybeit makes sense to almost have like a umlike an annotated rulings or something like that where you kind of talk aboutcases that come upumthat are not necessarily like you don'tneed to know for the spec but or it'salmost like a free class questions kindof thingummy feeling here is that there exists onename for real like the packet like whenyou go to install a package one is goingto win and that is what you shouldcompare againstand if there's any sort of discrepancythat's kind of a tooling problem but I guess maybe it would be useful for thespec to beumto note that such a thing can can comeup if that makes sense so for examplethe salsa verifier tooling Ian said downbelowum like when you go to invoke it on apackage all you have is a tarball so youdon't know the other name like you don'tknow what someone typed on the commandline and my feeling is that is a toolingproblem because it ought to beintegrated into the npm dueling and so that's kind of an implementation Gap asopposed to like some fundamentallike salsa spec thing so I I wouldn'tthat's anyway how my feeling is but doother folks have thoughtsmy thought on the matter was thatone of the expectationsthat I think users would have is thatthere's one name for the packageumand so to me it makes sense that if we'reit it makes sense to in the the salsaverifier toalso verify that that expectation thatthere's one package name that makessenseum if you have a if you just have aturbo there is only one package name butif you download from the npm registrythere's potentially two um different names one from the registryand one from the tarball that'scontained that that's downloadedum and so if the Providence like I Ifeel like if if the Providence isinstalling some kind of artifact or ifthe Providence is indicating the theinstant installation of the dependencyof some kind of artifactum that has a potential for a namemismatch then this seems like areasonable expectation for the salsa verifier toenforce that expectation just so thatanybody else who depends on it would beaware ofthe violation of or the confirmation ofthat expectationyeah so I think I agree withAndrew in that uh its effects like the umit's one of those areas where thespecification says there should be anagreement in the ecosystem and salsaverify uh uh it becomes part of theecosystem in this so there has to besome expectations set somewhere andthere'sit's kind of unappealing because assales verifier is trying to be a generictool hopefully it grows to supportmultiple ecosystems and if it has tohard code a bunch of assumptions abouthow to work around um you know gaps in the the Upstreamflow that could get quite unwieldy butumthat feels yeah that that to me is thethe challenging part of this but Laurenactually let you speak because you'remuch more people involved in thisuh well thanksum no I wanted to also mention somethingelse which is like the pub so I thinkthe publish at this station is not yet part of salsa which I think complicatesa little bit the discussion becauselike today we have salsa provenance butwe don't talk aboutpublish at this station and in thepackagename is only really relevant when you doumlike publish attestation verificationalthough the package name also ismentioned in the provenance itself but II think it's just alike I don't think it's it's really a a claim from the registryat that point but anyway what I wantedto say is I wonder whether there arealso two cases in terms of verificationthere's if you trust the registrydo you can you just verify the publishattestation and not verify what's insidethe uhthe doubleuh versus if you're trying to verify thesame way that the registry should verifyfor example if you have a network ofother entities that are trying to keepthe registry honest and do the same verification that in that case itclearly makes sense tolike to verify consistencyin the turbo versus what's in theuh what what the published attestationis claiming so I wonder whether thatmakes a difference or notuh in practiceeven though I kind of agree that if welike if we want verification to work foreveryoneeven even before the registry fixes the problem uh we might also want toto verify it in all the the two in thetwo cases that I'm mentioninguh I'm not I'm not sure if that makesclear what I'm saying I see Mark andChris have theretheir hands raisedum I I don't I don't see how publishattestations are irrelevant hereum like in my mind maybe I'm thinkingtoo abstractly but likefrom the purposes of a user you go to install a package and it in practice inthe npm kind of like thing on yourmachine gets installed with a nameand and you will encode refer to it bythat name or you will execute scripts orwhatever by that name and kind ofby installing it with a given nameyou're conferring the Privileges of thatname like you're using say underscore JSum in your project and you're calling itunderscore JS and referring to it or if this isum like a Debian install you are uhcalling something bash and you're it'sgiving the name you know user bin bashum and that and you know to know somesort of privilegeum and so that is the thing that youshould be comparing against expectationsthey're like what do I expect bash to beum under the hood ifif there are like publish attestations or or like whether or not you trust theregistry seems like[Music]uma little bit I'm not saying it shouldn'tbe in the specumbecause it clearly comes up but like itseems like it's kind of more of animplementation thing yeahI think Chris was nextuh yeah I I don't see how the publish attestation fits in here if you trustthe registry then the the registryshould probably be issuing a VSA and youverified the VSA and if you don't trustthe registry I don't care why you or Idon't understand why you care about thepublisher attestationit like you're installing from a localtarball that you have provenance for theregistry has kind of nothing to do withthat I would think Mark I think that early on in the issueI had a similarViewpoint as as you are describingum because I was coming at this from thebuild platforms perspectiveum if you have a build platform that iscapable of understanding thedependencies that are pulled on by thebuilds and includes that in Providence then it wouldI mean in in most situations it would itwould or it might use the npm registryfor mentioning or for identifying thosedependenciesum but what whatso from a build platform I think thatthe build platform itself is capable ofunderstandingthe provenance that it generates but then what Ian commented on it is it partof the issue during salsa verificationis that they have the Char ball and nota package name so it seems like that theissue is on the verification side theydon't have the metadata that'sin the npm registryum and and soif the build platform uses that metadatathat's in the npm registry thewhether that's the publicationattestation or or whatnot um there's still the the possibilitythat there's going to be a mismatchbecause maybe the the build platformuses that metadata of which theverification doesn't useum and so you're going to have uh you'renot going to be able to to verifytheprovenance that's generatedyeah that's that's actually what I was Iwas going to say is I I thinkum maybewhat would make sense for the spec is to say more explicitly that you can't wellI'm gonna say something controversialI'm not sure if everyone here will agreeuh you can't verify an artifact which isjust a file or blob of data you can youhave to verify an artifact commaresource or URI or some package packagename I thinksome I did package identifier pairbecause you are expecting this artifactto match the expectations of this resource nameum and it happens to be that somepackagesum have the name embedded in theartifact and maybe you could extractthat like npm packages happen to havethe name and tooling might be able tokind of Auto do it so you don't have topass in both explicitlyum but it sounds like that is the casehere that like the it's with theautomatic thing and sometimes theautomatic thing doesn't work uh I'd be interesting thoughts on that butLaura also had his hand up as wellwait I wanted to reply to what Chrissaid about like uh he said the registryhas nothing to do with uh if you have alocal double I guess maybe we didn'texplain the issue well but when youinstall you can download the toggle fromthe registry so the Registries isinvolved so you can download the toggleand then you can download theattestations which include theprovenance and the publish attestation and so the registry is involved it has apolicy that says that the registryaccepted that tableand its maps to that packageum I think Chris also mentioned VSA thepublished attestation is very similar itbasically gives you the package namewhich is the equivalent of the resourceURI in a VSAso the registry is still is stillinvolvedyeah that's all so I I'm not clear that we have aconclusion other than perhaps we weshould have a a list of of Appliedrulings on the website is there a consensus on what the rulingshould be in this casesort of separate applied ruling here Ithink after this discussion I thinkclarifyingin like the how to verify section Ithink actually doing it there might begoodumwhat do youat a high level you don't have to writethe details what do you all think aboutbeing more explicit about you need to verify on aartist like you don't verify an artifactalone you always verify an artifact anda package nameumand I can't talk a bit more about themechanics of how you look upwithout being prescriptive about how youlook up the thing based on effectivelykeyed by the package name and talk aboutthe special case of things like npmwhere the name is embedded in it um Lauren did you have your hand onfirst or is that remaininguh so I I thinkumI think what you described Mark makessense because we have documentation onthis within Celsius already that sayslike you don't just verify in artifactsyouverify an aspectum with this provenance against a set ofexpectations so I think we we'renarrowing in on being able to describesome more about what it or some of the like expectations that must be set upand I think that makes sense that we canprovide more clarityum and used npm example toumprovide further insights so I agreewith your proposal I guess just filling a bit of thesilence we have the the terminology pagehas a verification modeldescription and diagram as well as theverifying artifacts page so it feelslike we could add something uh or makesure that we're notum when we add something to address thiswe should make sure it's reflected inboth those places all right does does this comment I haveon the the screen look like a areasonable summary of the action itemsI would also addumthat I would say more explicitly that II have a wording in the meeting notes ifyou want to copy it got it okayforeign sure that that addresses all theconcerns but I I feel like that's goodto do either wayum but I'm hoping that that'll get us closer to resolutionsokay then let's wait for feedback on theissue and I'll I'll leave it on the thenew list to uh come back to next weekum and we're out of time so we'll we'llleave the rest of the of the backlogthere toothanks everyone thanks everyonebye here foreign foreign foreign foreign, SLSA Specifications Meeting, OpenSSF, 01h65a88h2403vnf4hyrym0k1g.