如何卸载 microsoft visual studio tools for git

1，就是你在安装这个软件以后，这个软件就自己带有一个卸载的程序，你只要点击：开始---程序---找到这个程序----上面就会有这个程序的卸载程序。

2，就是通过“添加与删除”来卸载，这个程序一般的WINDOS，自己都会带这个程序，你点：开始--控制面板---添加与删除----找到这个要卸载的程序---点删除就OK了。

3，就是利用第三方软件。

我用腾讯电脑管家举例（免费安全软件，杀毒+管理2合1）。

打开腾讯电脑管家——工具箱——软件卸载。

电脑管家是直接把软件卸载同时把注册列表也就清理了。（有的软件重启后会自动删除）卸载完之后，会有残留，在实行强力卸载

据外媒 BleepingComputer 报道，由于基础架构配置有误，来自技术、金融、电商、制造业等众多领域的数十家知名公司源码遭到泄露。

这些公司包括微软、Adobe、联想，AMD、高通，摩托罗拉、海思、任天堂、迪士尼、江森自控等，而且这一名单还在不断增长中。

来自瑞士的开发者 Tillie Kottmann 通过各类第三方源收集到了这些漏洞，他自己也找到了不少 DevOps 工具中的配置错误，而这些工具可以用来访问源代码。

遭泄露的源码被发布在 GitLab 上一个公开存储库中，并被标记为 “exconfidential” （绝密），以及 “Confidential & Proprietary”（保密&专有）。

（更新：GitLab 仓库均已被删除，Kottmann 现采用 telegram 群组来公布这些信息。）

根据安全研究人员 Bank Security 提供的信息，该存储库中大约包含了超过 50 家公司的源码。但有一些文件夹是空的，还有一些存在硬编码凭证——一种创建后门的方式。

Kottmann 提到，一些代码库中确实存在硬编码凭证，他在发布前已尽可能地将其删除，“以避免造成直接伤害或是助长更大的破坏”。另外，他也坦承自己并未在发布前与每一家受影响的公司进行联系，但他们确保自己“尽了最大的努力将负面影响最小化”。

目前，Kottmann 已应部分企业的要求删除了代码。例如 Daimler AG，梅赛德斯-奔驰的母公司；联想的文件夹也已经空空如也。针对有移除代码要求的公司，Kottmann 表示愿意遵守，并乐意提供信息，“帮助公司增强基础架构的安全性”。

事实上，从收到的 DMCA 通知数量（估计至多 7 份）和法律代表等的联系来看，许多公司仍对代码泄露事件不知情。另有部分公司没有撤除代码的意思，甚至有公司觉得“挺有趣”，只想知道 Kottmann 是如何获得代码的。

此次泄露的代码中，有一些项目早已由其原始开发者公开发布过，或是已经有很长时间不再更新和维护。网络安全公司 ImmuniWeb 的创始人兼首席执行官 Ilia Kolochenko 指出，“从技术角度来看，这次的泄露并不算很严重……若没有每天的支持和改进，源代码也会迅速贬值”。

尽管如此，这样大规模的泄露事件原因还是值得引起注意。许多公司使用错误的 DevOps 工具配置，引发源码暴露。Kottmann 及其团队近期正在 探索 运行 SonarQube 的服务器，他们发现，有成千上万的公司由于未能正确保护 SonarQube 安装而暴露了源码。

对于泄露源码的行为，安全专家 Jake Moore 对 科技 网站 Tom's Guide 表示，“失去对源代码的控制就像将银行蓝图交给抢劫犯一样……受影响的网站应立即采取保护措施……若用户在公司之前发现自己的数据遭到泄露，那无疑是在伤口上撒盐”。

基于法律层面，Kolochenko 认为源码发布者可能会因侵犯版权或违反计算机法而被起诉，但通常大型公司不会上诉，他们宁愿从存储库中快速删除源代码并修复其内部 DevOps 安全流程。

为此，Kolochenko 建议“企业应修改并持续监控 DevOps 操作，将其转换为敏捷的 DevSecOps”。

适用于 Linux 的 Windows 子系统中的 Visual Studio Code 服务器使用本地 WebSocket WebSocket 连接与远程 WSL 扩展进行通信。网站中的 JavaScript 可以连接到该服务器并在目标系统上执行任意命令。目前该漏洞被命名为CVE-2021-43907。

这些漏洞可以被用于：

本地 WebSocket 服务器正在监控所有接口。如果允许通过 Windows 防火墙，外部应用程序可能会连接到此服务器。

本地 WebSocket 服务器不检查 WebSocket 握手中的 Origin 标头或具有任何身份验证模式。浏览器中的 JavaScript 可以连接到该服务器。即使服务器正在监控本地主机，也是如此。

我们可以在特定端口上生成一个Node Inspector示例，它还监控所有接口。外部应用程序可以连接到它。

如果外部应用程序或本地网站可以连接到这些服务器中的任何一个，它们就可以在目标计算机上运行任意代码。

Visual Studio Code 库是不断更新的。我将使用一个特定的提交 (b3318bc0524af3d74034b8bb8a64df0ccf35549a)。

$ git clone https://githubcom/microsoft/vscode $ git reset --hard b3318bc0524af3d74034b8bb8a64df0ccf35549a

我们可以使用 Code (lol) 来导航源代码。事实上，我已经在 WSL 中为这个漏洞创建了具有相同扩展名的概念验证。

Visual Studio Code在 WSL 内以服务器模式运行，并与 Windows 上的代码示例对话（我称之为代码客户端）。这使我们可以在 WSL 中编辑文件和运行应用程序，而不需要运行其中的所有内容。

远程开发架构

可以通过 SSH 和容器在远程计算机上进行远程开发。GitHub Codespaces 使用相同的技术（很可能通过容器）。

在 Windows 上使用它的方法：

1打开一个WSL终端示例，在Windows上的代码中应该可以看到远程WSL扩展；

2在 WSL 中运行code /path/to/something；

3如果未安装代码服务器或已过时，则会下载它；

4VS Code 在 Windows 上运行；

5你可能会收到一个 Windows 防火墙弹出窗口，用于执行如下所示的可执行文件：

服务器的防火墙对话框

这个防火墙对话框是我执行失败的原因。出现该对话框是因为 VS Code 服务器想要监控所有接口。

从我信任的Process Monitor开始：

1运行进程监控器；

2在WSL中运行code ；

3Tools > Process Tree；

4我运行代码（例如，Windows Terminalexe）的终端示例中运行Add process and children to Include filte。

Procmon 的进程树

经过一番挖掘，我发现了 VSCODE_WSL_DEBUG_INFO 环境变量。我只是在 WSL 中将 export VSCODE_WSL_DEBUG_INFO=true 添加到 ~/profile 。运行服务器后我们会得到额外的信息。

VSCODE_WSL_DEBUG_INFO=true

输出被清理。

检查命令行参数。

可以看到出现了WebSocket词汇。

运行 Wirshark 并捕获loopback接口上的流量。然后我再次在 WSL 中运行代码。这次可以看到两个 WebSocket 握手。

在 Wireshark 中捕获的 WebSocket 连接

该运行中的服务器端口是63574，我们也可以从日志中看到。在 Windows 上的代码客户端中打开命令面板 (ctrl+shift+p) 并运行 > Remote-WSL: Show Log。

远程 WSL：显示日志

最后一行有端口：在 http://127001:63574/version 上打开本地浏览器。我们还可以看到从 Windows 上的 Code 客户端到服务器的两个单独的 WebSocket 连接。

服务器是位于 /src/vs/server/remoteExtensionHostAgentServerts#L207 的 RemoteExtensionHostAgentServer 的一个示例。

它被 createServer 在同一个文件中使用，我们可以使用 Code (lol) 找到它的引用并追踪到 remoteExtensionHostAgentts（同一目录）。

可以根据注释查看 mainjs 内部。

打开文件，看到服务器可以从传递给mainjs的参数中获得主机和端口。

mainjs 被 serversh 调用：

没有 IP 地址传递给脚本，我认为这就是为什么服务器监控所有有趣的事情。port=0 可能告诉服务器使用临时端口，此信息来自同一目录中的 wslServersh。

每次看到本地 WebSocket 服务器时，都应该检查谁可以连接到它。

WebSocket 连接不受同源策略约束，浏览器中的 JavaScript 可以连接到本地服务器。

WebSockets 从握手开始，在跨源资源共享或 CORS 的上下文中它始终是一个“简单”的GET 请求，因此浏览器不需要预先请求就可以发送它。

可以快速创建一个尝试连接到特定端口上的本地WebSocket服务器的测试页面，将它托管在某个远程位置（例如，S3 存储桶）并在计算机上打开它。如果连接成功，就可以继续操作了。

我还检查了 Burp，在 Burp Repeater 中创建了 WebSocket 握手。将 Origin 标头修改为 https://examplenet。如果响应具有 HTTP/11 101 交换协议，那么就可以继续了。

在 Burp 中测试

注意，这只对本地主机服务器有影响。这里的服务器也对外公开，攻击者不受浏览器约束。它们可以直接连接到服务器并提供任何 Origin 标头。

接下来是查看 Wireshark 中的流量，右键点击之前的WebSocket握手GET请求，然后选择 Follow > TCP Stream。我们将看到一个带有一些可读文本的屏幕。关闭它，只会看到这个进程的数据包，这允许我们只关注这个进程。

你可能会问为什么我关闭了仅包含消息内容的弹出窗口，因为没有用。根据 RFC6455，从客户端到服务器的消息必须被屏蔽。这意味着它们与一个 4 字节的密钥（也随消息一起提供）进行了异或运算。Wireshark 在选择时取消屏蔽每个数据包，但有效载荷在初始进程弹出窗口中显示为屏蔽。所以我们将看到纯文本的服务器消息，而客户端消息被屏蔽并出现乱码。如果你点击单个消息，Wireshark 就会显示有效载荷。

我花了几天时间对协议进行逆向工程。后来，我意识到只能在/src/vs/base/parts/ipc/common/ipcnetts 中看到协议的源代码。

来自服务器的第一条消息是 KeepAlive 消息。

在协议定义中，我们可以看到不同的消息类型。

在 /src/vs/platform/remote/common/remoteAgentConnectionts 中，它在代码的其他部分被称为 OKMessage 和heartbeat。

客户端在/src/vs/platform/remote/common/remoteAgentConnectionts的connectToRemoteExtensionHostAgent中处理此问题。客户端(Windows上的代码)发送这个包，它是一个KeepAlive和一个单独的认证消息。

最初，我认为长度字段是 12 个字节而不是 4 个字节，因为其余的字节总是空的。然后我意识到只有常规消息使用消息 ID 和 ACK 字段，而且我只看到了不规则的握手消息。

在修复之前，没有勾选此选项。

注意：在 2021-11-09 更新之前（commit b3318bc0524af3d74034b8bb8a64df0ccf35549a）客户端没有发送数据。但是，使用此提交，我们仍然可以在没有此密钥的情况下发送消息并且它会起作用。这是我们给服务器签名的内容，以检查连接到正确的服务器。

服务器响应一个签名请求。

另一个 JSON 对象：

服务器已经签名了我们在前一条消息中发送的数据，并用它自己的数据请求进行了响应。

客户端验证签名的数据，以检查它是否是受支持的服务器。当创建我们的客户端时，可以简单地跳过。

使用optionssignServicevalidate 方法，然后就会得到/src/vs/platform/sign/node/signServicets。

vsda 是一个用 C++ 编写的 Node 原生插件，将 Node 原生插件视为共享库或 DLL。该插件位于 https://githubcom/microsoft/vsda 的私有存储库中，根据https://librariesio/npm/vsda/的说法，直到2019年左右，它都是一个NPM包。

它与 VS Code 客户端和服务器捆绑在一起：

Windows系统：

C:\Program Files\Microsoft VS Code\resources\app\node_modulesasarunpacked\vsda\build\Release\vsdanode

服务器（WSL）：~/vscode-server/bin/{commit}/node_modules/vsda/build/Release/vsdanode。

我找到了https://githubcom/kieferrm/vsda-example，并通过一些实验找到了如何使用它创建和签名消息。

1用msg1 = validatorcreateNewMessage("1234")创建一个新消息，输入至少4个字符。

2使用signed1 = signersign(msg1)进行签名。

3使用 validatorvalidate(signed1) 对其进行验证，响应为“ok”。

需要注意的是，如果你创建了新消息，则无法再验证旧消息。在源代码中，每条消息都有自己的验证器。

Linux 版本有符号，大小约为 40 KB。把它放到 IDA/Ghidra 中，应该就可以开始了。

我花了一些时间，想出了这个伪代码。可能不太正确，但可以让你大致了解此签名的工作原理。

1用当前时间 + 2(msg[0]) 初始化 srand，它只会创建 0 到 9（含）之间的随机数；

2从许可证数组中附加两个随机字符；

3从 salt 数组中附加一个随机字符；

4SHA256；

5Base64；

6；

7Profit。

仅从许可证数组中选择前 10 个位置的字符，它总是 rand() % 10 ，但salt 数组翻了一番。

许可证数组的字符串如下所示：

salt 数组的前 32 个字节（查找 Handshake::CHandshakeImpl::s_saltArray）是：

我从来没有真正检查过我的分析是否正确，不过这无关紧要，知道如何使用插件签名消息，这就足够了。

接下来，客户端需要签名来自服务器的数据并将其发送回来，以显示它是一个“合法”的代码客户端。

服务器响应如下：

客户端发送了如下消息：

提交应该匹配服务器的提交哈希。这不是秘密。这可能是最后一个稳定版本提交（或最后几个之一）。这只是检查客户端和服务器是否在同一版本上。它也可以在 http://localhost:{port}/version 上找到，你的浏览器 JavaScript 可能无法看到它，但外部客户端没有这样的限制。

signedData是对我们在前面消息中从服务器获得的数据进行签名的结果。

Args是此消息中最重要的部分，它可以告诉服务器在特定端口上启动一个 Node Inspector 示例。

break: 启动 Inspector 示例后中断。

端口：检查器示例的端口。

Env：传递给检查器示例进程的环境变量及其值的列表。

Node Inspector 示例可用于调试 Node 应用程序。如果攻击者可以连接到你计算机上的此类示例，那么攻击就成功了。2019 年，Tavis 发现 VS Code 默认启用了远程调试器。

整个设置旨在允许 Windows 上的代码客户端在 WSL、容器或 GitHub 代码空间中进行远程开发。这意味着它可以在远程计算机上做任何想做的事情。

因此，如果网站可以连接到你本地的 WebSocket 服务器并绕过 DRM，它就可以模拟代码客户端。它可以在你的系统上远程执行代码，并且不需要 Node Inspector 示例。

到目前为止，我们已经找到了两种利用该系统的方法：

生成并连接到 Node Inspector 示例；

模拟代码客户端并使用自定义协议与远程计算机交互；

Node Inspector示例

让我们看看前面消息中的参数， /src/vs/server/remoteExtensionHostAgentServerts 在服务器上处理它们。

IRemoteExtensionHostStartParams 接口类似于我们之前看到的 JSON 对象：

_updateWithFreeDebugPort检查端口是否空闲，如果没有，它将尝试接下来的10个端口。最后一个空闲端口存储在startParamsport中。

选择的端口被发送回客户端，所以我们知道去哪里：

最后，它在 /src/vs/server/extensionHostConnectionts 中调用constart(startParams);。

这看起来很复杂，让我们来分析一下：

1Node Inspector 示例将监听 0000:debugPort，这很危险，如果用户接受 Windows 防火墙对话框，它将在外部可用；

2我们也可以注入 Inspector 的环境变量；

3removeDangerousEnvVariables 方法不是安全过滤器，只是删除 DEBUG、DYLD_LIBRARY_PATH 和 LD_PRELOAD 环境变量（如果存在）以防止崩溃。

什么是Node Inspector？

它可以用来调试Node进程。有一些客户端和库支持这一点，但通常，我使用Chromium内置的专用节点DevTools (chrome|edge://inspect)。

连接到 Inspector 示例后，我们可以打开控制台并运行 require('child_process')exec('calcexe');。尽管我们使用的是wsdl，但它仍然有效。

浏览器中的 JavaScript 无法连接到 Inspector 示例，客户端使用另一个 WebSocket 连接与示例对话。但是，我们需要知道调试器会话 ID。

/json/列表

浏览器中的 JavaScript 可以发送此 GET 请求，但由于 SOP（响应没有 Access-Control-Allow-Origin 标头）而无法看到响应。其他客户端则没有这个限制，因为检查器在外部可用，我们可以从外部连接到它。

现在，我创建了一个简单的概念验证：

1打开一个网站并输入端口（我们可以扫描它，但手动输入它会更快）。

2网站中的 JavaScript 完成握手。

3我使用 /sign API 创建了一个 Node 应用程序，这样就可以使用 vsda 插件。

4一旦生成Node Inspector 示例，第二个 API 就会被 debugPort 调用。

5使用 chrome-remote-interface 库的 Node 应用程序连接到 Inspector 示例并运行 calc。

你可以通过以下链接看到源代码：

https://githubcom/parsiya/code-wsl-rce https://githubcom/parsiya/Parsia-Code/tree/master/code-wsl-rce

模拟代码客户端

创建客户端并使用协议连接到服务器的代码位于 VS Code GitHub 存储库中，这需要大量的复制/粘贴和解析，我只花了几个小时。

如果要创建一个快速的概念验证，应该满足一些假设：

1找到本地的 WebSocket 端口；

2从外部连接到Node Inspector示例；

查找本地 WebSocket 端口并不难，从浏览器扫描本地服务器并不是什么新鲜事。服务器也可以从外部使用，因此我们不受那里的浏览器约束。

Chrome 限制不起作用，因为 WebSocket 服务器需要一个网络服务器来处理握手。我也很好奇 WebSocket 节流是 Chrome 特定的保护还是 Chromium 的一部分。

有趣的是，Chrome 浏览器有一个保护机制，可以防止恶意行为者暴力破解 WebSocket 端口，它在第 10 次尝试后开始节流。不幸的是，这种保护很容易被绕过，因为扩展的 HTTP 和 WebSocket 服务器都在同一个端口上启动。这可用于通过向 img 标签添加 onload 处理程序来检查特定本地主机端口上的是否存在来强制所有可能的本地端口。

也就是说，这是一个开发环境，用户可能整天都在 WSL 中开发并且从不关闭他们的浏览器选项卡，因此如果他们打开我们的网站，我们就有可能找到它。

连接到Node Inspector示例是另一回事，我们无法从浏览器执行此操作，因此我们需要我们的服务器可以访问受害者的计算机。

第二种利用方法（模拟代码客户端）没有这些限制，因为浏览器可以与本地服务器通信并执行所有操作。它只需要我们对协议进行逆向工程并找出要发送的正确消息。

当你收到 WebSocket 升级请求时，请根据许可名单检查 Origin 标头。代码客户端在该标头中发送 vscode-file://vscode-app，以便我们可以使用它来操作。

参考及来源：https://parsiyanet/blog/2021-12-20-rce-in-visual-studio-codes-remote-wsl-for-fun-and-negative-profit/

您好，python和ndk没有用最新的

　　主要原因是之前搞的时候最新的有bug

　　于是沿用之前成功的版本

　　下面就是骨头一路上的碰壁：

　　流水帐开始：

　　1

　　首先在公司的win8上安装vs2013半点问题没有

　　用vs2013打开之前用vs2012下创建的项目提示不好用

　　愿意是我忽略的升级配置文件的选项。

　　2

　　尝试微软提供的项目管理软件：TFS，申请微软的免费服务器。

　　发现功能太强大，适合大项目的项目管理，但我只需要源代码管理就行。

　　放弃，尝试git。

　　3

　　被vs2013打开过的cocos2dx项目，在2012中打开又报错了。

　　看来需要彻底升级了。

　　4

　　下载解压cocos2dx30beta版本。

　　使用create_projectpy创建项目比之前友好了

　　因为换成了图形界面

　　不过先进命令行的方式还是太麻烦

　　我们建个快捷方式：

　　建一个bat文件

　　输入D:\Java\cocos2d-x-30beta\tools\project-creator\create_projectpy

　　5

　　cocos2dx30beta建的新项目比之前大了

　　因为他直接把编译所需代码拷贝到项目文件夹下

　　而且可建立在任意位置

　　6

　　新项目建立之后vs2013运行ok

　　于是拷贝到github的本地代码库下

　　上传（几百M，略大，稍等）

　　上传ok之后直接打开本地代码库下的sln文件

　　此时，vs2013会自动配置好git

　　骨头实验了一下提交到本地和提交到服务器功能

　　ok

　　7

　　回家捣鼓笔记本安装vs2013

　　（win81已装vs2012）

　　老报核心什么什么的错

　　搜了网上几乎所有的办法：管理员、换显卡驱动、打补丁（个人不喜欢一切win的补丁）

　　还是不成功

　　于是系统还原到一个没装vs2012的ghost

　　可以安装了（不计较了 vs那么大，有点问题可以理解）

　　8

　　装完vs2013就开始装python装cygwin

　　结果到后来发现好像不需要cygwin了

　　cmd进入到projandroid下

　　敲入 python build_nativepy 命令cmd开始编译

　　省去了之前版本需要用cygwin编译而且需要修改文件权限的步骤

　　心惊胆颤的直到发现 so文件ok

　　9

　　eclipse打开其中的android项目

　　导入不报错，运行黑屏。

　　果然没那么幸运

　　网上一搜说需要：

　　把cocos2d-x-30beta/cocos/2d/platform/android/java/src/org/cocos2d-x/lib整个文件夹拷贝到你的项目下projAndroid/src/org/cocos2d-x下

　　感觉这个步骤完全可以新建cocos2dx项目时脚本自动加上

　　应该是错误漏掉了

　　估计下次升级就不需要手动加了

　　加上之后再次运行

　　终于看到熟悉的土豆了

　　10

　　下一步就是在建一个cocos2dx的源码管理

　　由于之前试验过

　　应该没啥问题

　　就不加到流水帐了

　　11

　　回家搞vs2013和github果然有问题。

　　主要是新的cocos2dx30beta生成的项目太大了

　　空项目编译运行一次竟然高达800多M

　　于是学习了下git的配置文件的使用：

　　gitignore

　　关键是这个文件正常来说windows不让建立

　　多敲一个。就行。

搜索凭据管理器，添加普通凭据。

windows没有安全中心git报错，搜索凭据管理器，添加普通凭据，重新尝试错误提示。

Windows是美国微软公司以图形用户界面为基础研发的操作系统，主要运用于计算机、智能手机等设备。

工具：win10Win10系统打开“运行”窗口方法如下：方法一：1、在系统的开始菜单上单击鼠标右键2、弹出的菜单中点击运行3、这样就打开了系统的运行对话框方法二：1、点击开始菜单，然后点击所有应用2、然后找到windows应用中的运行打开方法三：按下键盘的“微软窗口图标+R”组合键即可快捷打开。

双击安装文件，打开安装窗口，进入Information界面

点击“next”按钮，进入Select Destination Location界面，可根据自己的需求修改安装路径

点击“next”按钮，进入Select Componets界面，选择要安装的组件。

图标组件(Addition icons) : 选择是否创建快速启动栏图标 或者 是否创建桌面快捷方式;

桌面浏览(Windows Explorer integration) : 浏览源码的方法, 单独的上下文浏览 只使用bash 或者 只用Git GUI工具; 高级的上下文浏览方法 使用git-cheetah plugin插件;

关联配置文件 : 是否关联git配置文件, 该配置文件主要显示文本编辑器的样式;

关联shell脚本文件 : 是否关联Bash命令行执行的脚本文件;

使用TrueType编码 : 在命令行中是否使用TruthType编码, 该编码是微软和苹果公司制定的通用编码;

点击“next”，进入Select Start Menu Folder界面，设置开始菜单中快捷方式的目录名称,

点击“next”，进入Adjusting your PATH environment界面，设置环境变量 ：选择使用什么样的命令行工具, 一般情况下我们默认使用Git Bash即可, 默认选择。

Git自带 : 使用Git自带的Git Bash命令行工具;

系统自带CMD : 使用Windows系统的命令行工具;

二者都有 : 上面二者同时配置, 但是注意, 这样会将windows中的findexe 和 sortexe工具覆盖, 如果不懂这些尽量不要选择;

点击“next”按钮进入Configuring the line ending conversions界面，选择换行格式，选择“Checkout as-is, commit Unix-style line endings”，

检查出windows格式转换为unix格式 : 将windows格式的换行转为unix格式的换行在进行提交;

检查出原来格式转为unix格式 : 不管什么格式的, 一律转为unix格式的换行在进行提交;

不进行格式转换 : 不进行转换, 检查出什么, 就提交什么;

点击“next”按钮进入配置终端模拟器（Configuring the terminal emulator to use with Git Bash）界面，默认设置

点击“next”按钮进入额外的配置选项（Configuring extra options），默认设置。

点击“Install“开始安装，安装完毕后，点击”finish“

简单来说，包管理器 package manager 是一种工具，它允许用户在操作系统上安装、删除、升级、配置和管理软件包。

软件包管理器可以是像“软件中心”这样的图形化应用，也可以是像 apt-get 或 winget 这样的命令行工具。

包管理器是一个通用的概念，它并不是 Linux 独有的。你会经常发现各种软件或编程语言的包管理器。有只是针对 Python 包的 PIP 包管理器。甚至 Atom 编辑器也有自己的包管理器。

一个包 package 通常指的是一个应用程序，它可以是一个 GUI 应用程序、命令行工具或（其他软件程序需要的）软件库。包本质上是一个存档文件，包含二进制可执行文件、配置文件，有时还包含依赖关系的信息。

在旧时代，软件曾经是从它的源代码安装的。你会参考一个文件（通常命名为 README ），看看它需要什么软件组件、二进制文件的位置。它通常包括一个配置脚本或 Makefile 。你必须自己编译该软件或自己处理所有的依赖关系（有些软件需要安装其他软件）。

为了摆脱这种复杂性，Linux 发行版创建了自己的打包格式，为终端用户提供随时可用的二进制文件（预编译软件），以便安装软件，同时提供一些元数据（版本号、描述）和依赖关系。

这就像烤蛋糕与买蛋糕一样。

大约在上世纪 90 年代中期，Debian 创建了 DEB 打包格式（deb），Red Hat Linux 创建了 RPM（Red Hat Package Manager 的缩写）打包系统（rpm）。编译源代码的方式仍然存在，但现在是可选的。

打包系统就是所有相同打包格式的集合仓库，要与打包系统交互或使用打包系统，你需要一个包管理器来拉取下载打包系统中的包，也就是我们常说的软件。

每个打包系统都有一个或者多个包管理工具。

包管理器分为：通用软件包管理器和应用程序级软件包管理器。与系统级软件包管理器相比，应用级软件包管理器专注于软件系统的一小部分，为开发人员提供所需要的编程语言的各种库。

Linux下有：

APT:是Debian及其派生的Linux软件包管理器。APT可以自动下载，配置，安装二进制或者源代码格式的软件包，因此简化了Unix系统上管理软件的过程。APT最早被设计成dpkg的前端，用来处理deb格式的软件包。现在经过APT-RPM组织修改，APT已经可以安装在支持RPM的系统管理RPM包。

Yum是由Duke University团队修改Yellow Dog Linux的Yellow Dog Updater开发而成，是一个基于RPM包管理的字符前端软件包管理器。能够从指定的服务器自动下载RPM包并且安装，可以处理依赖性关系，并且一次安装所有依赖的软件包，无须繁琐地一次次下载、安装。被Yellow Dog Linux本身，以及Fedora、Red Hat Enterprise Linux采用。

dpkg：最初由Debian使用，现在由Ubuntu使用。使用deb格式，是第一个拥有广为人知的依赖性解决工具APT。

当然，还有很多，就不一一列举出来了！

Windows下有：

Chocolatey: 以Yum和apt-get的精神为基础的Windows开源分散式软件包管理器。

pacman: MSYS2移植的Windows版本的Arch Linux软件包管理器。

Scoop：一个用于Windows的命令行安装程序。

WinGet：（Windows 程序包管理器：Windows Package Manager）是微软为 win10 开发的一款开源的软件包管理器。

MacOS下有：

Mac App Store:OS X应用程序的官方数字分销平台。

Homebrew:MacOS的软件包管理器，基于Git。

Fink: dpkg的移植，它是最早的macOS的软件包管理器之一。

几乎都是各大开发语言的库管理相关。

gitee： https://giteecom/cmcc-oneos/OneOS-Lite

docs： https://oneos-litecom/

公众号：CMCC-OneOS