Odeslání manifestu do úložiště

Po vytvoření manifestu balíčku , který popisuje vaši aplikaci, jste připraveni odeslat manifest do úložiště Správce balíčků systému Windows. Jedná se o veřejně přístupné úložiště, které obsahuje kolekci manifestů, ke kterým má nástroj winget přístup. Manifest odešlete tak, že ho nahrajete do opensourcového úložiště https://github.com/microsoft/winget-pkgs na GitHubu.

Jakmile odešlete žádost o přijetí změn pro přidání nového manifestu do úložiště GitHub, automatizovaný proces ověří soubor manifestu a zkontroluje, jestli balíček splňuje zásady správce balíčků Systému Windows a není známo, že je škodlivý. Pokud je ověření úspěšné, váš balíček se přidá do veřejného úložiště Správce balíčků systému Windows, aby ho mohl zjistit klientský nástroj winget. Všimněte si rozdílu mezi manifesty v opensourcovém úložišti GitHub a veřejným úložištěm Správce balíčků Systému Windows.

Důležité

Společnost Microsoft si vyhrazuje právo odmítnout odeslání z jakéhokoli důvodu.

Ověření manifestu

Když odešlete manifest do úložiště https://github.com/microsoft/winget-pkgs na GitHubu, manifest se automaticky ověří a vyhodnotí z hlediska bezpečnosti ekosystému Windows. Manifesty lze také zkontrolovat ručně.

Další informace o procesu ověření najdete v části procesu ověření níže.

Jak odeslat manifest

Pokud chcete odeslat manifest do úložiště, postupujte takto.

Krok 1: Ověření manifestu

Nástroj winget poskytuje příkaz validate pro ověření, že jste manifest vytvořili správně. K ověření manifestu použijte tento příkaz.

winget validate \<path-to-the-manifests>

Pokud ověření selže, vyhledejte číslo řádku za pomoci chyb a proveďte opravu. Po ověření manifestu ho můžete odeslat do úložiště.

Krok 2: Otestování manifestu pomocí sandboxu Windows

Úložiště Správce balíčků systému Windows obsahuje skript, který nainstaluje Správce balíčků systému Windows do pískoviště pro testování odeslaného manifestu. Pokud chcete spustit skript PowerShellu, přejděte do úložiště winget-pkgs. V PowerShellu zadejte následující příkaz:

powershell .\Tools\SandboxTest.ps1 manifests\m\Microsoft\VisualStudioCode\1.56.0

Možná budete muset tento skript aktualizovat správnou cestou k souboru manifestu: .\Tools\SandboxTest.ps1 <path to manifest or manifest folder>

Podívejte se na úplný testovací skript pro sandbox v repozitáři winget-pkgs.

Krok 3: Klonování úložiště

Vytvoření forku úložiště Správce balíčků systému Windows a naklonování úložiště do místního počítače:

1. V prohlížeči přejděte na https://github.com/microsoft/winget-pkgs a vyberte Fork.

2. Z příkazového řádku windows nebo PowerShellu naklonujte fork pomocí následujícího příkazu.

   git clone --filter=blob:none --no-checkout <your-fork-name>
   

Krok 4: Nastavení sparse checkoutu

Řídký checkout vám umožní zvolit, které části úložiště chcete stáhnout, místo stažení všeho. V předchozím kroku znamená, --filter=blob:none že historie potvrzení ještě nebyla stažena, a --no-checkout znamená to, že do pracovní kopie (index) ještě nebyly přidány žádné soubory.

Před stažením čehokoli budete muset zadat filtry pro řídký checkout k použití (uložené v .git/info/sparse-checkout).

Nejdřív tady je vysvětlení toho, co se má nastavit. Soubory manifestu je nutné přidat do úložiště v následující struktuře složek:

manifesty / dopis / vydavatel / aplikace / verze

• manifesty složka je kořenová složka pro všechny manifesty v úložišti.
• písmeno složka je první písmeno názvu vydavatele malými písmeny. Například m vydavatele Microsoftu.
• Složka vydavatele je název společnosti, která software publikuje. Například Microsoft.
• Složka aplikace je název aplikace nebo nástroje. Například VSCode.
• Složka verze je verze aplikace nebo nástroje. Například 1.0.0.

Hodnoty PackageIdentifier a PackageVersion v manifestu musí odpovídat vydavateli, názvům aplikací a verzím v cestě ke složce manifestu. Další informace najdete v tématu Vytvoření manifestu balíčku.

Pokud tedy chcete nastavit řídké odhlašování pro všechny manifesty vydavatele, zadejte:

• Pokud používáte verzi Gitu 2.37.0 nebo novější, spusťte následující příkaz k nastavení řídké kontroly pro vaši složku.

  git sparse-checkout set manifests\<letter>\<publisher>
  

• Pokud používáte starší verzi Gitu, přečtěte si dokumentaci k Gitu pro informace o nastavení řídkého výběru místního úložiště.

Všimněte si, že výše uvedený příkaz přepíše všechna aktuální nastavení řídké rezervace a nastaví ho jenom pro jednu složku, přečtěte si dokumentaci Gitu k nastavení řídké rezervace s více složkami.

Krok 5: Vytvoření kopie úložiště

Nyní můžete použít nastavení řídkého checkoutu spuštěním normálního příkazu checkout.

git checkout

I když složka, kterou chcete odeslat, ještě nebyla potvrzena do úložiště, musíte přesto spustit příkaz Git checkout, protože nebude možné přidat (a potvrdit) cokoli bez nastavení Git interních souborů (indexu).

Pokud zadáváte více příspěvků, vytvořte místo forku větev. V současné době povolujeme pouze jeden soubor manifestu na odeslání.

git checkout -b <branch-name>

Krok 6: Přidání manifestu do místního úložiště

Přidejte soubory do následující složky (formát je vysvětlený v kroku 4): manifesty / dopisy / vydavatel / aplikace / verze

Krok 7: Odeslání manifestu do vzdáleného úložiště

Teď jste připraveni odeslat nový manifest do vzdáleného úložiště.

1. Pomocí příkazu commit přidejte soubory a potvrďte změnu a zadejte informace o odeslání.

   git commit -m "Submitting ContosoApp version 1.0.0" --all
   

2. Pomocí příkazu push odešlete změny do vzdáleného úložiště.

   git push
   

Krok 8: Vytvoření pull requestu

Po nasdílení změn se vraťte do https://github.com/microsoft/winget-pkgs a vytvořte žádost o přijetí změn pro sloučení forku nebo větve do hlavní větve.

Proces odeslání

Když vytvoříte žádost o přijetí změn, spustí se automatizovaný proces, který ověří manifesty a ověří vaši žádost o přijetí změn. Během tohoto procesu spustíme testy s instalačním programem a nainstalovanými binárními soubory pro ověření odeslání.

Do žádosti o přijetí změn přidáme popisky, abyste mohli sledovat její průběh. Další informace o popiscích a procesu najdete v části popisky žádostí o přijetí změn níže.

Po dokončení bude vaše odeslání ručně zkontrolováno moderátorem a po schválení se vaše aplikace přidá do katalogu Správce balíčků systému Windows.

Pokud během procesu dojde k chybě, dostanete oznámení a naše štítky a robot vám pomohou s opravou odeslání. Seznam běžných chyb najdete v části ověřovacího procesu níže.

Proces ověření

Když vytvoříte žádost o přijetí změn k odeslání manifestu do úložiště Správce balíčků systému Windows, spustí se proces automatizace, který ověří manifest a zpracuje vaši žádost o přijetí změn. Popisky GitHubu se používají ke sdílení průběhu a umožňují vám komunikovat s námi.

Očekávání odeslání

Všechna odeslání aplikací do úložiště Správce balíčků systému Windows by měla dodržovat zásady úložiště Správce balíčků systému Windows.

Očekávání pro odeslání:

• Manifest splňuje požadavky schématu .
• Všechny adresy URL v manifestu vedou k bezpečným webům.
• Instalační program a aplikace jsou bez virů. Balíček může být omylem identifikován jako malware. Pokud se domníváte, že je to falešně pozitivní, můžete odeslat instalační program týmu programu Microsoft Defender pro analýzu.
• Aplikace se nainstaluje a odinstaluje správně jak pro správce, tak pro uživatele bez administrátorského oprávnění.
• Instalační program podporuje neinteraktivní režimy.
• Všechny položky manifestu jsou přesné a nejsou zavádějící.
• Instalační program pochází přímo z webu vydavatele.

Úplný seznam zásad najdete v tématu zásady Správce balíčků systému Windows.

Štítky k pull requestům

Během ověřování se na žádosti o přijetí změn aplikuje série štítků pro komunikaci průběhu. Některé popisky vás nasměrují k provedení akce, zatímco jiné budou přesměrovány do technického týmu Správce balíčků systému Windows.

Popisky stavu

Následující tabulka popisuje popisky stavu , se kterými se můžete setkat.

Štítek	Podrobnosti
Azure-Pipeline-Prošel	Manifest dokončil testovací fázi. Čeká na schválení. Pokud během testu nedojde k žádným problémům, automaticky se schválí. Pokud se test nezdaří, může být označen k manuálnímu přezkoumání.
Blokující-problém	Tento popisek označuje, že pull request nemůže být schválen, protože existuje blokující problém. Často můžete zjistit, v čem je problém s blokováním, podle přiloženého popisku chyby.
vyžaduje pozornost	Tento popisek znamená, že pull request musí prozkoumat vývojový tým správce balíčků systému Windows. Důvodem je buď selhání testu, které vyžaduje ruční kontrolu, nebo komentář přidaný do žádosti o přijetí změn komunitou.
potřeby – zpětné vazby	Značí selhání odeslání. Pull request vám znovu přiřadíme. Pokud problém nevyřešíte do 10 dnů, robot pull request uzavře. štítky, které vyžadují autorovu zpětnou vazbu, se obvykle přidají v případě selhání žádosti o přijetí změn, která vyžaduje aktualizaci, nebo pokud má recenzent žádosti dotaz.
ověření dokončeno	Značí, že test byl úspěšně dokončen a váš pull request bude sloučen.

Popisky chyb

Následující tabulka popisuje popisky chyb , se kterými se můžete setkat. Okamžitě se vám nepřiřadí všechny případy chyb. Některé můžou aktivovat ruční ověření.

Štítek	Podrobnosti
Binary-Validation-Error	Aplikace zahrnutá v tomto pull requestu neprošla testem instalačního skenu . Tento test je navržený tak, aby se zajistilo, že se aplikace nainstaluje do všech prostředí bez upozornění. Další podrobnosti o této chybě najdete v části Binární ověřování níže.
vypršení časového limitu analýzy chyb	Časový limit testu Binary-Validation-Test vypršel. Žádost o přijetí změn se přiřadí technikovi Správce balíčků systému Windows, který to prozkoumá.
Neshoda hash hodnot	Odeslaný manifest nelze zpracovat, protože hodnota hash InstallerSha256 poskytnutá pro InstallerURL se neshodovala. Aktualizujte InstallerSha256 v žádosti o přijetí změn a zkuste to znovu.
Chyba-Instalátor-Dostupnost	Ověřovací služba nemohla stáhnout instalační program. Může to souviset s blokovanými rozsahy IP adres Azure nebo může být nesprávná adresa URL instalačního programu. Zkontrolujte, zda je InstallerURL správný a zkuste to znovu. Pokud máte pocit, že došlo k chybě, přidejte komentář a žádost o přijetí změn se přiřadí technikovi Správce balíčků systému Windows, který to prozkoumá.
Chyba ověřování instalačního manifestu	Během vyhodnocení balíčku MSIX existují nekonzistence nebo hodnoty, které v manifestu neexistují.
manifest-Path-Error	Soubory manifestu musí být vloženy do konkrétní struktury složek. Tento popisek označuje problém s cestou odeslání. Například struktura složek nemá požadovaný formát. Aktualizujte svůj manifest a znovu odešlete žádost o přijetí změn.
Chyba při ověřování manifestu	Odeslaný manifest obsahuje chybu syntaxe. Vyřešte problém se syntaxí manifestu a odešlete ho znovu. Podrobnosti o formátu manifestu a schématu najdete v požadovaném formátu.
chyba PullRequest-Error	Žádost o přijetí změn je neplatná, protože ne všechny odeslané soubory jsou ve složce manifestu nebo existuje více balíčků nebo verzí v žádosti o přijetí změn. Aktualizujte žádost o přijetí změn, aby se problém vyřešil, a zkuste to znovu.
URL-Validation-Error	Ověřovací test URL nemohl najít adresu URL a odpověděl kódem chyby HTTP (403 nebo 404) nebo se nezdařil test reputace adresy URL. Pokud se podíváte na podrobnosti kontroly pull requestu, můžete určit, která adresa URL je v otázce. Pokud chcete tento problém vyřešit, aktualizujte příslušné adresy URL a vyřešte stavový kód chyby HTTP. Pokud příčinou problému není stavový kód chyby HTTP, můžete odeslat adresu URL ke kontrole, abyste se vyhnuli selhání reputace.
Validation-Defender-Error	Během dynamického testování program Microsoft Defender nahlásil problém. Chcete-li tento problém reprodukovat, nainstalujte aplikaci a spusťte úplnou kontrolu v programu Microsoft Defender. Pokud můžete problém reprodukovat, opravte binární soubor nebo ho odešlete k analýze pro falešně pozitivní pomoc. Pokud se vám problém nedaří reprodukovat, přidejte komentář, který technikům Správce balíčků Systému Windows umožní problém prozkoumat.
validation-domain	Test určil doménu, pokud InstallerURL neodpovídá očekávané doméně. Zásady Správce balíčků systému Windows vyžadují, aby instalační program pocházel přímo z umístění vydání nezávislého výrobce softwaru. Pokud se domníváte, že se jedná o falešnou detekci, přidejte do žádosti o přijetí změn komentář, aby technici Windows Správce balíčkůu mohli prozkoumat.
chyba ověřování	Ověření Správce balíčků systému Windows selhalo během ručního schvalování. Další kroky najdete v doprovodném komentáři.
Chyba ověřování programu	Během testování instalace nebyl test schopen najít primární aplikaci. Ujistěte se, že se aplikace správně nainstaluje na všechny platformy. Pokud vaše aplikace nenainstaluje program, ale přesto by měla být zahrnuta do úložiště, přidejte do žádosti o přijetí změn komentář, aby technici spravující Windows Správce balíčků mohli situaci prošetřit.
Ověření hodnoty hash– ověření se nezdařilo	Během testování instalace se aplikace nepodaří nainstalovat, protože InstallerSha256 už neodpovídá hash InstallerURL. K tomu může dojít, pokud je aplikace za okrasnou URL adresou a instalační program byl aktualizován bez aktualizace InstallerSha256. Pokud chcete tento problém vyřešit, aktualizujte InstallerSha256 přidružené k InstallerURL, a odešlete ho znovu.
Validation-HTTP-Error	Adresa URL použitá pro instalační program nepoužívá protokol HTTPS. Aktualizujte InstallerURL, aby používal protokol HTTPS, a znovu odešlete pull request .
Nepřímé ověřování URL	Adresa URL neschází přímo ze serveru isV. Testování zjistilo, že se použil přesměrovač. To není povoleno, protože zásady Správce balíčků systému Windows vyžadují, aby InstallerUrl pocházel přímo z výchozího umístění vydání poskytovatele softwaru. Odeberte přesměrování a znovu odešlete.
Chyba při ověřování instalace	Během ručního ověření tohoto balíčku došlo k obecné chybě. Další kroky najdete v doprovodném komentáři.
Ověření-Konflikt-Sloučení	Tento balíček nelze ověřit kvůli konfliktu při sloučení. Vyřešte konflikt při slučování a znovu odešlete svůj pull request.
Validace-MSIX-Závislost	Balíček MSIX má závislost na balíčku, kterou nelze vyřešit. Aktualizujte balíček tak, aby zahrnoval chybějící komponenty, nebo přidejte závislost do souboru manifestu a znovu odešlete žádost o přijetí změn.
ověření neschválená URL	Test určil doménu, pokud InstallerURL neodpovídá očekávané doméně. Zásady Správce balíčků systému Windows vyžadují, aby instalační program pocházel přímo z umístění vydání nezávislého výrobce softwaru.
neúspěšné bezobslužné ověření	Během instalace vypršel časový limit testu. Je to pravděpodobně způsobeno tím, že aplikace se neinstaluje tiše. Příčinou může být také některá jiná chyba, ke které došlo a zastavení testu. Ověřte, že manifest můžete nainstalovat bez vstupu uživatele. Pokud potřebujete pomoc, přidejte do žádosti o přijetí změn komentář a technici Windows Správce balíčkůu prošetří.
validation-uninstall-error	Během testování odinstalace se zjistilo, že aplikace po odinstalaci nezanechala systém úplně čistý. Další podrobnosti najdete v doprovodném komentáři.
Ověření-VCRuntime-Závislost	Balíček je závislý na modulu runtime C++, který nelze rozpoznat. Aktualizujte balíček tak, aby zahrnoval chybějící komponenty, nebo přidejte závislost do souboru manifestu a znovu odešlete žádost o přijetí změn.

Popisky zásad obsahu

Následující tabulka uvádí popisky zásad obsahu. Pokud je některý z těchto popisků přidán, něco v metadatech manifestu aktivovalo další ruční kontrolu obsahu, aby se zajistilo, že metadata následují zásady Správce balíčků systému Windows.

Štítek	Podrobnosti
Policy-Test-2.1	Viz obecné požadavky na obsah.
Policy-Test-2.2	Podívejte se na obsah včetně jmen, log, originálního a externího obsahu
Policy-Test-2.3	Viz Riziko poškození.
policy-test-2.4	Viz Pomlouvačné, Nactiutrhačné, Urážlivé a Výhružné.
policy-test-2.5	Viz urážlivý obsah.
policy-test-2.6	Viz alkohol, tabák, zbraně a drogy.
Policy-Test-2.7	Viz obsah pro dospělé.
Policy-Test-2.8	Viz nelegální aktivity.
Policy-Test-2.9	Viz nadměrnou vulgárnost a nevhodný obsah.
Policy-Test-2.10	Viz požadavky specifické pro zemi nebo oblast.
policy-test-2.11	Viz věkové hodnocení.
Policy-Test-2.12	Viz uživatelem generovaný obsah.

Interní popisky

Následující tabulka uvádí popisky vnitřních chyb. Když dojde k interním chybám, přiřadí se vaše žádost o přijetí změn technikům Správce balíčků systému Windows, kteří ji prošetří.

Štítek	Podrobnosti
Interní-Chyba-Doména	Při ověřování domény adresy URL došlo k chybě.
Internal-error-dynamic-scan	Při ověřování nainstalovaných binárních souborů došlo k chybě.
Interní-Chyba-Klíčové-Slovo-Politika	Při ověřování manifestu došlo k chybě.
manifest vnitřní chyby	Při ověřování manifestu došlo k chybě.
interní chyba - žádné architektury	Došlo k chybě, protože test nemohl určit architekturu aplikace.
interní chyba - nepodporované architektury	Došlo k chybě, protože aktuální architektura není podporována.
Internal-Error-PR pro chybu	Při zpracování žádosti o přijetí změn došlo k chybě.
interní-chyba-statické-skenování	Během statické analýzy instalačních programů došlo k chybě.
Interní adresa URL chyby	Při ověřování reputace instalačních programů došlo k chybě.
vnitřní chyba	Během spuštění testu došlo k obecné chybě nebo neznámé chybě.

Chyba binárního ověřování

Pokud ověření vaší žádosti o přijetí změn selže v testu Installers Scan a obdrží popisek Binary-Validation-Error, znamená to, že se vaší aplikaci nepodařilo nainstalovat do všech prostředí.

Test skenování instalačních programů

Aby byl poskytnut skvělý uživatelský zážitek při instalaci aplikací, musí správce balíčků systému Windows zajistit, aby se všechny aplikace nainstalovaly na počítače bez chyb, bez ohledu na prostředí. Jedním z klíčových testů je zajistit, aby se všechny aplikace nainstalovaly bez upozornění na různé oblíbené antivirové konfigurace. Systém Windows poskytuje integrovaný antivirový program v programu Microsoft Defender, ale mnoho podnikových zákazníků a uživatelů používá jiný antivirový software.

Každé odeslání do úložiště Správce balíčků systému Windows se spouští prostřednictvím několika antivirových programů. Všechny tyto programy mají různé algoritmy detekce virů pro identifikaci potenciálně nežádoucích aplikací (PUA) a malwaru.

Řešení chyb binárního ověřování

Pokud aplikace selže ověření, Microsoft se nejprve pokusí ověřit u dodavatele antivirového softwaru, jestli je označený software falešně pozitivní. V mnoha případech po oznámení a ověření dodavatel antivirového softwaru aktualizuje svůj algoritmus a aplikace projde.

V některých případech nemůže dodavatel antivirového softwaru určit, jestli je zjištěná anomálie kódu falešně pozitivní. V takovém případě není možné aplikaci přidat do úložiště Správce balíčků systému Windows. Žádost o přijetí změn se odmítne s popiskem Binary-Validation-Error.

Pokud se u vašeho pull requestu zobrazí popisek Binary-Validation-Error, aktualizujte software k odstranění kódu rozpoznaného jako PUA.

Někdy se legitimní nástroje používané k ladění a aktivitám nízké úrovně zobrazují jako PUA pro antivirový software. Příčinou je to, že nezbytný ladicí kód má podobný podpis jako nežádoucí software. I když je tento postup kódování legitimní, úložiště Správce balíčků systému Windows bohužel nemůže tyto aplikace povolit.

Řešení potíží s odesláním

Pokud odeslání Správce balíčků systému Windows selže, můžete pomocí popisků popsaných výše prošetřit příčinu selhání.

Pokud chcete prošetřit selhání žádostí o přijetí změn, proveďte následující kroky:

1. Ve spodní části webové stránky se zobrazí selhání pull requestu s řetězcem Některé kontroly nebyly úspěšné. Chcete-li přejít na stránku Azure Pipelines, vyberte odkaz Podrobnosti vedle položky, u které došlo k selhání ověření.

   

2. Na stránce Azure Pipelines vyberte odkaz 0 chyb / 0 varování.

   

3. Na další stránce vyberte neúspěšnou úlohu.

   

4. Na další stránce se zobrazí výstup neúspěšné úlohy. Výstup by vám měl pomoct identifikovat změnu, kterou je potřeba provést k opravě manifestu.

   V následujícím příkladu došlo k chybě během úlohy Ověření instalace.