MétaCan
Menu
← Retour à la cohorte
Enregistrement W6893633029 · doi:10.5281/zenodo.3989073

hpcng/singularity: Singularity 3.6.0

2020· other· en· W6893633029 sur OpenAlexaff

Notice bibliographique

RevueZenodo (CERN European Organization for Nuclear Research) · 2020
Typeother
Langueen
Domaine
Thématique
Établissements canadiensTellabs (Canada)
Organismes subventionnairesnon disponible
Mots-clésSingularityMistakeSign (mathematics)Signature (topology)HeaderContainer (type theory)

Résumé

récupéré en direct d'OpenAlex

Singularity 3.6.0 is an important security release, as well as including a large number of new features and improvements. Please read the release notes below carefully, especially regarding the security content and compatibility of SIF signatures. In particular, note that 3.6.0 necessarily uses a new format for SIF signatures, which is incompatible with older versions of Singularity. 3.6.0 has a --legacy-insecure flag to verify the older insecure signatures temporarily if needed in your workflows, but older versions cannot verify containers signed by 3.6.0. Security related fixes Singularity 3.6.0 introduces a new signature format for SIF images, and changes to the signing / verification code to address: CVE-2020-13845 In Singularity 3.x versions below 3.6.0, issues allow the ECL to be bypassed by a malicious user. CVE-2020-13846 In Singularity 3.5 the --all / -a option to singularity verify returns success even when some objects in a SIF container are not signed, or cannot be verified. CVE-2020-13847 In Singularity 3.x versions below 3.6.0, Singularity's sign and verify commands do not sign metadata found in the global header or data object descriptors of a SIF file, allowing an attacker to cause unexpected behavior. A signed container may verify successfully, even when it has been modified in ways that could be exploited to cause malicious behavior. Please see the published security advisories at https://github.com/hpcng/singularity/security/advisories for full detail of these security issues. Note that the new signature format is necessarily incompatible with Singularity < 3.6.0 - e.g. Singularity 3.5.3 cannot verify containers signed by 3.6.0. We thank Tru Huynh for a report that led to the review of, and changes to, the signature implementation. New features / functionalities Singularity now supports the execution of minimal Docker/OCI containers that do not contain /bin/sh, e.g. docker://hello-world. A new cache structure is used that is concurrency safe on a filesystem that supports atomic rename. If you downgrade to Singularity 3.5 or older after using 3.6 you will need to run singularity cache clean. A plugin system rework adds new hook points that will allow the development of plugins that modify behavior of the runtime. An image driver concept is introduced for plugins to support new ways of handling image and overlay mounts. Plugins built for <=3.5 are not compatible with 3.6. The --bind flag can now bind directories from a SIF or ext3 image into a container. The --fusemount feature to mount filesystems to a container via FUSE drivers is now a supported feature (previously an experimental hidden flag). This permits users to mount e.g. sshfs and cvmfs filesystems to the container at runtime. A new -c/--config flag allows an alternative singularity.conf to be specified by the root user, or all users in an unprivileged installation. A new --env flag allows container environment variables to be set via the Singularity command line. A new --env-file flag allows container environment variables to be set from a specified file. A new --days flag for cache clean allows removal of items older than a specified number of days. Replaces the --name flag which is not generally useful as the cache entries are stored by hash, not a friendly name. A new '--legacy-insecure' flag to verify allows verification of SIF signatures in the old, insecure format. A new '-l / --logs' flag for instance list that shows the paths to instance STDERR / STDOUT log files. The --json output of instance list now include paths to STDERR / STDOUT log files. Changed defaults / behaviours New signature format (see security fixes above). Environment variables prefixed with SINGULARITYENV_ always take precedence over variables without SINGULARITYENV_ prefix. The %post build section inherits environment variables from the base image. %files from ... will now follow symlinks for sources that are directly specified, or directly resolved from a glob pattern. It will not follow symlinks found through directory traversal. This mirrors Docker multi-stage COPY behaviour. Restored the CWD mount behaviour of v2, implying that CWD path is not recreated inside container and any symlinks in the CWD path are not resolved anymore to determine the destination path inside container. The %test build section is executed the same manner as singularity test image. --fusemount with the container: default directive will foreground the FUSE process. Use container-daemon: for previous behavior. Fixed spacing of singularity instance list to be dynamically changing based off of input lengths instead of fixed number of spaces to account for long instance names. Deprecated / removed commands Removed --name flag for cache clean; replaced with --days. Deprecate -a / --all option to sign/verify as new signature behavior makes this the default. Bug Fixes Don't try to mount $HOME when it is / (e.g. nobody user). Process %appinstall sections in order when building from a definition file. Ensure SINGULARITY_CONTAINER, SINGULARITY_ENVIRONMENT and the custom shell prompt are set inside a container. Honor insecure registry settings from /etc/containers/registries.conf. Fix http_proxy env var handling in yum bootstrap builds. Disable log colorization when output location is not a terminal. Check encryption keys are usable before beginning an encrypted build. Allow app names with non-alphanumeric characters. Use the base metapackage for arch bootstrap builds - arch no longer has a base group. Ensure library client messages are logged with --debug. Do not mount $HOME with --fakeroot --contain. Fall back to underlay automatically when using a sandbox on GPFS. Fix Ctrl-Z handling - propagation of signal. Thanks to our contributors for code, feedback and, testing efforts! As always, please report any bugs to: https://github.com/sylabs/singularity/issues/new If you think that you've discovered a security vulnerability please report it to: security@sylabs.io Have fun!

Récupéré en direct depuis OpenAlex et désinversé. Les résumés ne sont pas conservés dans cette base de données : les index inversés représentent 8,6 Go des 9,3 Go de texte de la base, et le serveur dispose de 13 Go libres.

Comment cette classification a été obtenuedéplier

Prédiction machine sur la base complète

Imitation des enseignants

Ni prévalence calibrée, ni vérité terrain. Validation humaine à venir. Le volet Gemma est une étiquette directe du modèle pour chaque travail de la base, lue sur la notice réduite au titre. Le volet Codex est un classifieur appris des 10 348 étiquettes directes de Codex et calibré sur les taux pondérés de l'échantillon; les champs sans appui suffisant ne portent aucun appel Codex. Le mode candidate est l'union des deux volets; le consensus est leur intersection. Ces sorties portent le statut machine_predicted_unvalidated et ne sont pas des étiquettes humaines.

score de la tête « metaresearch » (Codex)0,004
score de la tête « metaresearch » (Gemma)0,023
Version: metacan-v3-hybrid-931329e0061cStatut de validation: machine_predicted_unvalidated
Catégories candidatesaucune
Catégories consensuellesaucune
DomaineSignal candidat: aucune · Signal consensuel: aucune
Devis d'étudeSignal candidat: Sans objet · Signal consensuel: Sans objet
GenreSignal candidat: Logiciel · Signal consensuel: Logiciel
Score de désaccord entre enseignants0,203
Score d'incertitude au seuil0,679

Scores du classifieur distillé par catégorie (deux têtes)

CatégorieCodexGemma
Métarecherche0,0040,023
Méta-épidémiologie (sens strict)0,0020,002
Méta-épidémiologie (sens large)0,0010,002
Bibliométrie0,0010,001
Études des sciences et des technologies0,0010,001
Communication savante0,0060,007
Science ouverte0,0050,005
Intégrité de la recherche0,0020,005
Charge utile insuffisante (le modèle a refusé de juger)0,2030,240

Scores machine (provisoires)

Les deux têtes enseignantes du modèle étudiant, lues sur ce travail. Un score ordonne la base pour la relecture; il n'affirme jamais une catégorie, et le statut de validation accompagne chaque rangée tel quel.

Scores de référence d'un modèle non mature (critères de maturité non atteints, 7 itérations). Un score ordonne; il n'affirme jamais une catégorie.

Tête enseignante Opus0,041
Tête enseignante GPT0,254
Écart entre enseignants0,212 · la distance entre les deux têtes enseignantes sur ce seul travail
Statut de validationscore_only:v0-immature-baseline · tel quel depuis la passe de notation : score_only signifie que le nombre peut ordonner les travaux, et qu'aucune étiquette de catégorie n'en découle

Classification

machine, non validée

Prédiction automatique; un appel candidat d’une seule source (Gemma direct ou Codex distillé), pas un consensus.

Les modèles n’ont appliqué aucune catégorie : rien dans la taxonomie ne correspondait à ce travail.
Devis d'étudeSans objet
Domainenon disponible
GenreLogiciel

Le détail, modèle par modèle et score par score, se trouve en fin de page sous « Comment cette classification a été obtenue ».

En bref

Citations0
Publié2020
Routes d'admission1
Résumé présentoui

Explorer davantage

Même revueZenodo (CERN European Organization for Nuclear Research)→Travaux en français237 207→