Changelog 4ec6606 Add README and MIT license ef24c9d Add repository automation and signed releases 35b829d Bump github.com/cloudflare/circl from 1.6.1 to 1.6.3 5361cef Bump github.com/go-git/go-gi...

CTO Thomas Aynaud on the SWHID: How the new ISO standard defeats fragile dependencies and guarantees code integrity.

RSD adopts SWHIDs. This integration ensures permanent archiving and verifiable reproducibility for over 1,000 software packages.

Agustín Benito Bethencourt discusses the role of SWHID in modern compliance and its application in safety-critical software environments.

« Software identification is crucial for ensuring the long-term traceability of scholarly outputs. However, identifying software can be complex, resembling an investigation requiring tailored solut…

swhid 0.5.0 improves reference conformance and cuts memory use when hashing large files and Git repositories. It adds streaming content hashing and validates more malformed directory, snapshot, and...

New Ambassador Wendi Urribarri on using SWHIDs to bridge the gap between open source and automotive safety regulations.

New Ambassador Wendi Urribarri on using SWHIDs to bridge the gap between open source and automotive safety regulations.

The ISO standard for the SWHID specification marks a milestone in establishing a framework for identifying software.

The ISO standard for the SWHID specification marks a milestone in establishing a framework for identifying software.

Research software is not data, and the FAIR principles — designed for data — do not carry over to it unchanged. These doctoral course notes take software as a first-class research output and work through what it takes to archive it, reference it precisely, and reproduce the results built on it. They introduce Software Heritage, the universal archive of source code, and the SWHID (ISO/IEC 18670) intrinsic identifier that names any source-code artefact by a cryptographic hash of its content. From there they build up software citation with the biblatex-software style, the qualified identifiers that pin an exact version, module or line range in context, and the practical workflows — Save Code Now, self-archival, artefact evaluation — that let a paper point at code that will still be there, and still be the same, years later. Written for PhD students and researchers across disciplines, suitable for self-study or taught delivery.

All B-type subdwarf stars (hereafter sdB) should have low flux of ionizing photons, making them incapable of producing a noticeable circumstellar photoionized shell. However, a few sdB stars have been associated with circumstellar nebulae, resembling in some cases a planetary nebula. These discoveries spark doubts about the nature of the physical processes behind the formation of the nebula. In this paper, we describe the newfound parabolic-shaped nebula associated with the high proper motion sdB star TYC 3315-1807-1. The apex of the Halpha nebula is situated approximately 0.5 arcmin in the direction of the stellar proper motion. A wider parabolic-shaped nebula is also detected in WISE W1 infrared images at 3.4 micron, whereas GALEX images show extended far-UV emission around the star within the optical and mid-IR emissions. Like most other sdB stars with associated nebulae, TYC 3315-1807-1 moves at a high-speed (102 km/s) across the Galactic plane. The low luminosity of TYC 3315-1807-1 cannot provide its wind with the momentum necessary to form and keep a bow shock. The nebula around TYC 3315-1807-1 is rather suggested to be a Mach wave partially excited by shocks and photoionization or the encounter of the star with an over-density clump in the ISM.

« (…) Au programme : actualités DataCite, ORCID, SWHID, Baromètre de la science ouverte, catalogue Recherche Data Gouv… et un atelier pratique pour plonger dans le schéma de métadonnées DataC…

Session Overview Roberto Di Cosmo and Morane Gruenpeter of Software Heritage discuss the key concepts relating to software identifiers in academia and also explored the value of intrinsic vs extrinsic software identifiers. Speaker Bios RobertoDi Cosmo (Founder, CEO) After teaching for almost a decade at Ecole Normale Supérieure in Paris, Roberto Di Cosmo became full professor in Computer Science at University Paris Cité. He is currently on leave at Inria to lead the Software Heritage project. His research interests span a wide spectrum from foundational aspects of logical systems to functional programming, parallel and distributed programming. He created and directed the European reseach project, Mancoosi, to improve the quality of large collections of software quality, and is investigating the scientific problems posed by the general adoption of Free Software, with a particular focus on static analysis of large software collections. A long term Free Software advocate, contributing to its adoption since 1998, he has created the Free Software thematic group of Systematic in October 2007, which has helped fund over 40 research and development projects. He is now director of IRILL, a research structure dedicated to Free and Open Source Software quality. Morane Gruenpeter (Head of Open Science) After several years as a professional harpist, Morane found a new career path in software engineering. Morane joined the Software Heritage team in 2017 while finishing a Master’s degree in Computer Science at University Pierre et Marie Curie in Paris. From 2018-2019, she continued her research in collaboration with the European EU2020 CROSSMINER project on the software metadata challenge by building the Semantic Web of FOSS projects. Then from 2020-2022, she represented Inria in the FAIRsFAIR project. In 2022, her role evolved as she assumed managment responsibilities as the Work Package 6 lead in the FAIRCORE4EOSC project and Work Package 3 lead in the SoFAIR project, which started in January 2024. Morane is an active member of several working groups and initiatives for OpenScience, including: the CodeMetainitiative, the ResearchData Alliance’s Software Source Code interest group and the SciCodesconsortium. As part of Software Heritage Open Science activities, Morane is the contact point for the SCOSS fundraising campaign and for the OpenScience partnerships, overseeing a variety of partnerships with entities suchas the CCSD-HAL-Episciences, IPOL, eLife, Zenodo-InvenioRDM, SwMath, Dagstuhl,and others.

<p>ELISA Project Seminar Series focuses on hot topics related to ELISA’s mission to define and maintain a common set of elements, processes and tools that can be incorporated into Linux-based, safety-critical...</p>\n

Bastien Guerry from Software Heritage recently nerd-sniped me with an idea for a `git-remote-swh` that would let you `git clone` from a SWHID, pulling source code directly from Software Heritage’s archive by content hash rather than by URL. Building that means writing a git remote helper, which sent me back to the gitremote-helpers docs and down the rabbit hole of how many of these things already exist. I covered remote helpers briefly in my earlier post on extending git functionality, but the protocol deserves a closer look. A `git-remote-swh` would need to be an executable on your `$PATH` so that git invokes it when it sees a URL like `swh://`. The helper and git talk over stdin/stdout using a text-based line protocol. For `git-remote-swh` the end goal would be something like: git clone swh://swh:1:rev:676fe44740a14c4f0e09ef4a6dc335864e1727ca;origin=https://github.com/wikimedia/mediawiki Or using the double-colon form, which reads a bit cleaner when adding a remote: git remote add archive swh::swh:1:rev:676fe44740a14c4f0e09ef4a6dc335864e1727ca;origin=https://github.com/wikimedia/mediawiki The SWHID identifies a specific revision by content hash, and the `origin` qualifier tells the helper where to fall back if that revision isn’t in the archive yet. The helper would resolve the SWHID against Software Heritage’s archive, and if the revision isn’t archived yet, use the `origin` qualifier to ask Software Heritage to import it first, so the clone always comes through the archive and can be verified against the content hash. You’d end up with `git clone` as a content-addressed fetch primitive rather than just a URL fetch, which is an interesting building block for reproducible builds and supply chain verification. Git opens by sending `capabilities` and the helper responds with what it can do: `fetch`, `push`, `import`, `export`, `connect`, or some combination. A SWHID helper would only need `import` and `list` since Software Heritage is a read-only archive and its API returns objects individually rather than as packfiles. `import` lets the helper pull snapshots, revisions, trees, and blobs via the REST API and stream them into git’s fast-import format, which is easier to implement than `fetch` where you’d have to reconstruct packfiles yourself for not much gain on a read-only helper. `connect` establishes a bidirectional pipe where git speaks its native pack protocol as if it were talking to a real git server, but that only makes sense when the remote actually speaks git’s wire protocol. After capability negotiation, git sends `list` to get the remote’s refs, then issues import commands in batches. For a SWHID helper, `list` would resolve the SWHID against Software Heritage’s API, translate the archive’s snapshot into a ref listing, and then `import` would stream the objects through as fast-import data. Each batch ends with a blank line, and the helper responds with status lines like `ok refs/heads/main` or `error refs/heads/main <reason>`. Writing a remote helper from scratch is more work than writing a git subcommand but less work than building a full git server. Most implementations are a few hundred to a few thousand lines of code, and the hardest part is mapping git’s object model onto whatever storage backend you’re targeting. Software Heritage already stores git objects natively, so a SWHID helper might be one of the easier ones to build. ### Built-in Git ships with remote helpers for its standard network transports, and they follow the same protocol as everything else below. * **git-remote-http** / **git-remote-https** implement the smart HTTP protocol that most hosted git services use * **git-remote-ftp** / **git-remote-ftps** fetch over FTP, though this is rarely used in practice * **git-remote-ext** pipes git’s protocol through an arbitrary command, which makes it a building block for custom transports without writing a full remote helper ### Cloud and object storage * **git-remote-dropbox** stores git repos in Dropbox using the Dropbox API, and is one of the better documented remote helpers if you’re looking for implementation examples. * **git-remote-s3** from AWS Labs uses S3 as a serverless git server with LFS support. Written in Rust. There are several other S3-backed helpers floating around but this is the most complete. * **git-remote-codecommit** provides authenticated access to AWS CodeCommit repositories without needing to configure SSH keys or manage HTTPS credentials manually. * **git-remote-rclone** pushes and fetches through rclone, so it gets rclone’s 70+ cloud storage providers for free: Google Drive, Azure Blob Storage, Backblaze B2, and the rest. ### Encryption * **git-remote-gcrypt** encrypts an entire git repository with GPG before pushing it to any standard git remote. The remote stores only encrypted data, so you can use an untrusted host as a private git server with multiple participants sharing access through GPG’s key infrastructure. * **git-remote-encrypted** takes a different approach where each git object is individually encrypted before being stored as a file in a separate git repository. The remote looks like a normal git repo full of encrypted blobs. * **git-remote-keybase** was part of the Keybase client and stored encrypted git repos on Keybase’s infrastructure using the Keybase identity and key management system. Keybase was acquired by Zoom in 2020 and the service has been winding down since. ### Content-addressed storage * **git-remote-ipfs** maps git objects onto IPFS, storing repositories in a content-addressed merkle DAG. Written in Go using the IPFS API. Several other IPFS-based remote helpers exist (dhappy/git-remote-ipfs, git-remote-ipld, Git-IPFS-Remote-Bridge) taking slightly different approaches to the same problem. ### VCS bridges * **git-remote-hg** lets you clone and push to Mercurial repositories transparently using git commands, converting between the two object models on the fly using the fast-import/fast-export capabilities. * **git-remote-bzr** does the same for Bazaar repositories, also by Felipe Contreras. * **git-remote-mediawiki** treats a MediaWiki instance as a git remote where each wiki page becomes a file. You can clone a wiki, edit pages locally with your text editor, and push changes back. Written in Perl. ### P2P and decentralised * **git-remote-gittorrent** distributed git over BitTorrent, using a DHT for peer discovery and Bitcoin’s blockchain for user identity. A research prototype from 2015 that demonstrated the concept but never saw wide adoption. * **git-remote-nostr** publishes git objects as Nostr events, using the relay network for distribution. * **git-remote-blossom** builds on the Blossom protocol, a Nostr-adjacent system for content-addressed blob storage. * **git-remote-ssb** stored repositories on Secure Scuttlebutt, a gossip-based peer-to-peer protocol where data replicates through social connections rather than central servers. Dormant since the SSB ecosystem contracted. ### Transport wrappers These don’t provide their own storage or collaboration model, they wrap existing git remotes with a different transport layer, closer in spirit to the built-in `git-remote-ext` than to the storage-backed helpers above. * **git-remote-tor** routes git traffic through Tor hidden services, written in Rust. ### Blockchain * **git-remote-gitopia** pushes repositories to Gitopia, a code collaboration platform built on the Cosmos blockchain where repository metadata and access control live on-chain. ### Other storage backends * **git-remote-sqlite** stores git objects as rows in a SQLite database, which can then be replicated using tools like Litestream. * **git-remote-restic** bridges git and restic backup repositories, inheriting restic’s encryption and support for dozens of storage backends. * **git-remote-couch** stores git repos in CouchDB, gaining CouchDB’s replication and conflict resolution for free. * **git-remote-grave** pushes repositories into a content-addressable store that deduplicates across multiple repos. If I’ve missed one, reach out on Mastodon or submit a pull request on GitHub.

A webinar from the EDUC-WIDE Seminar Series From Data to Code: How Libraries advance Open Science practices on source code Through Data Management Clusters PDF version link to reusable files Seminar Series Abstract In their general policy on Open Science, the University of Rennes encourages its researchers to archive their source code in Software Heritage, link source code to publications deposited in HAL to improve visibility, use standards such as SWHID to connect publications and source codeHowever, most of the source code produced by our researchers is likely hosted on GitHub, often without an explicit license permitting reuse, and has not been made visible on our University’s HAL Portal, which is managed by the Library. Our researchers can rely on a Data Management Cluster (ARDoISE) to help them manage and share their datasets in accordance with the FAIR principles. As a librarian at my university and, within ARDoISE, the person responsible for advising researchers on source code management and visibility, I will provide an overview of the efforts being made to address these challenges within our research community. I will also describe some of the steps we have already taken to foster collaboration with other stakeholders qualified to guide researchers on source code management. Additionally, I will outline potential future opportunities to increase compliance to our university’s Open Science policy regarding research source code.