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

Confidence Indicator of Detection Methods

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

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Ferma
Stack tecnologico
csharp
Ambito
devtools

Direzione di ricerca

Non sono indicati file, test o punti di ingresso. Inizia esaminando come i rilevatori ordinano i controlli e come sono rappresentati i risultati del rilevamento; quindi definisci i quattro livelli di affidabilità, associa i controlli a ciascuno di essi e determina come deve apparire l'indicatore di affidabilità nell'output. Il lavoro è completato quando la classificazione è coerente tra i rilevatori e i risultati espongono il livello di affidabilità.

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

Descrizione

From @jonthysell in prior PR comment:

If this really is a runtime check (and not a static check as per my earlier comment) I would prefer if we listed them by highest to least confidence (I can update the template to reflect this):

  1. (Maybe never attainable) We unambiguously detect part of a framework being used in the running app (i.e. a control rendered at runtime)
  2. We see markers of a framework being used (i.e., class name / UIA identifiers) that could technically be spoofed or mistaken because there's no namespace enforcement
  3. We detect that the framework's module was loaded by the process (process could load a module transitively that doesn't actually get used by the app, also naming issues)
  4. We detect a (transitive) dependency via a package manifest (again, could be marked as a dependency but not actually used by the app)

This ordering should also be reflected in the detector as closely possible.

We should probably have this definition "baked in" vs. determined by the defined order within a detector (i.e. we don't want to try and have to coordinate between detector authors how to order specific checks within their detector).

We should define what the above criteria is and how various checks fall within their ranks. Then, since we run all checks, we can order by the confidence level and include that indicator as part of the output/results?

Lingua principale
C#
Stelle
10
Fork
4
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

  • Nessun Dockerfile né file Docker Compose
  • Ha un modello di pull request
  • Nessuna guida per i contributori

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 microsoft/FrameworkDetector

Tutte le issue di microsoft/FrameworkDetector

Issue simili

Altre issue su C#

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.