Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

jf audit: PEP 621 Support for Poetry Projects

Aperta
  • Qualcosa non va?
#560 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 2 giorni

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
48/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Ferma
Stack tecnologico
go, python
Ambito
security

Direzione di ricerca

Esegui la riproduzione con Poetry 2.x e jf audit --poetry, quindi traccia il rilevamento delle dipendenze di Poetry utilizzato dal comando di audit. Confronta la gestione di [tool.poetry.dependencies] con [project].dependencies e aggiungi la copertura di regressione per la forma PEP 621; il lavoro è completato quando viene trovato l’albero delle dipendenze e l’audit non segnala più che non sono state trovate dipendenze.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

bug
Describe the bug

Upshot: jf audit fails to scan the dependencies in a Poetry project that uses Python's standardized metadata format.

Background:

Poetry's 2.0 release introduced support for the standard Python project metadata specification defined in PEP 621. For the purposes of this issue, the relevant change is the ability to declare the dependencies of a Poetry-managed project in a format that is agnostic to any given package manager. For now, Poetry supports both this standard specification as well as its proprietary format. Regardless of how the dependencies are specified, it will produce an equivalent lock file in which only the "content-hash" will differ. Poetry offers a nice summary of dependency specification behavior here, but I will provide a short example of the new behavior in the "Current behavior" field.

When running jf audit on a project using the PEP 621 spec to declare dependencies instead of the poetry.dependencies table, jf finds no dependencies. If I move the dependencies to the poetry.dependencies table and run poetry lock, I see the lock file is unchanged except for the hash, but jf audit now works as expected.

Current behavior

Here is how a Poetry project might have looked prior to 2.0:

[project]
name = "jfrog-mre"
version = "0.1.0"
description = ""
authors = [
    {name = "John Doe",email = "[email protected]"}
]
readme = "README.md"

[tool.poetry]
packages = [{include = "jfrog_mre", from = "src"}]

[tool.poetry.dependencies]
python = ">=3.13"
aiostream = ">=0.7.0,<0.8.0"

[build-system]
requires = ["poetry-core>=2.0.0,<3.0.0"]
build-backend = "poetry.core.masonry.api"

Running

poetry lock
jf audit --poetry

on this project yields the expected output

Vulnerable Dependencies
┌──────────────────── ┐
│ ✨ No vulnerable dependencies were found ✨ │

If I modify the project metadata to use the PEP 621 syntax:

[project]
name = "jfrog-mre"
version = "0.1.0"
description = ""
authors = [
   {name = "John Doe",email = "[email protected]"}
]
readme = "README.md"

# this is the important change
requires-python = ">=3.13"
dependencies = [
    "aiostream (>=0.7.0,<0.8.0)"
]

[tool.poetry]
packages = [{include = "jfrog_mre", from = "src"}]

[build-system]
requires = ["poetry-core>=2.0.0,<3.0.0"]
build-backend = "poetry.core.masonry.api"

and re-lock

poetry lock

I see no real modification to the dependencies.

diff --git a/poetry.lock b/poetry.lock
index 0d3c2a0..e589f79 100644
--- a/poetry.lock
+++ b/poetry.lock
@@ -33,4 +33,4 @@ files = [
 [metadata]
 lock-version = "2.1"
 python-versions = ">=3.13"
-content-hash = "778650c6e329a706cab7f61d4dcd2898837a1e5fd40f6675a3b5388489183176"
+content-hash = "b5186d11c92a12923c8b3316939bcfa0cd91669bb1c9ccdf51250e9e759cd6f7"

Yet, running jf audit --poetry now yields

13:10:50 [🔵Info] Log path: .../.jfrog/logs/jfrog-cli.2025-09-05.13-10-50.46472.log
13:10:53 [🔵Info] Trace ID for JFrog Platform logs: 31070edaf54eac57
13:10:53 [🚨Error] target '.../repos/tmp/jfrog-mre [poetry]' errors:
failed to generate SBOM for .../repos/tmp/jfrog-mre: failed to build dependency tree: no dependencies were found. > Please try to build your project and re-run the audit command

Reproduction steps
  • Install the latest version (or at least 2.0+) of Poetry: https://python-poetry.org/docs/#installation
  • Create a new Poetry project. Via Poetry's CLI, you can run poetry new jfrog-mre
  • From the project's root, add a dependency via Poetry's CLI, e.g. poetry add aiostream
  • Run jf audit --version
Expected behavior

jf audit should work with Poetry projects that use the PEP 621 project spec.

JFrog CLI-Security version

2.78.9

JFrog CLI version (if applicable)

jf version 2.78.9

Operating system type and version

macOS 15.6.1, MacBook Pro M2 Pro

JFrog Xray version

No response

Lingua principale
Go
Stelle
13
Fork
52
Merge medio
2g 11h
PR unite (30g)
22

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di jfrog/jfrog-cli-security

Tutte le issue di jfrog/jfrog-cli-security

Issue simili

Altre issue su Go

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.