1.Github的码分使用
2.华为云服务器实战 之 Gitlab安装与配置使用
3.Gitlab Cookie 反序列化漏洞研究
4.开源协议专题(七)：BSD、MIT、码分ApacheL
5.GitLab ARM64源码在信创统信UOS下的码分搭建
Github的使用
GitHub 是一个用于存放和共享软件代码的平台，使用 Git 进行版本控制。码分开发者通过 Ruby on Rails 编写它，码分由 Chris 码分修改jar源码Wanstrath、PJ Hyett 和 Tom Preston-Werner 创立。码分GitHub 可以让你的码分代码开源，也可以作为私有项目使用。码分
如何使用 Clone 功能？简单来说，码分就是码分将远程项目下载到本地电脑。操作步骤包括：创建代码库、码分填写仓库名称、码分指定本地保存路径。码分页面有翻译，码分英语不熟练的用户可以对照操作。
要开始一个项目，可以在 GitHub 上搜索相关代码。比如，如果你需要写基金量化代码，可以搜索“基金量化”。GitHub 将列出多个相关源码供你选择。
上传代码到 GitHub 非常方便。选择“创建代码库”，填入项目名，指定本地保存路径。然后点击“上传”按钮，完成代码上传。除了上传代码，你还可以使用其他功能，如切换分支、上传同步分支、删除分支和合并分支。
如果你觉得这个教程对你有帮助，请在下方点赞。商品销售源码如果有任何疑问或建议，欢迎在评论区留言。GitHub 是一个充满活力的社区，期待你的贡献。
华为云服务器实战 之 Gitlab安装与配置使用
GitLab是一个基于Ruby on Rails的开源应用程序，它允许用户自托管Git项目仓库，并通过Web界面访问公开或私人项目。它提供了类似GitHub的功能，如浏览源代码、管理缺陷和注释，以及管理团队对仓库的访问权限。GitLab易于浏览提交的版本并提供文件历史库，团队成员还可以利用内置的聊天程序进行交流。
GitLab的安装和配置主要在华为云服务器上进行。首先，确保服务器配置至少4G内存。通过xshell连接到服务器，并安装必要的依赖，如ssh、防火墙、postfix（用于邮件通知）和wget。安装成功后，可以开启相应的服务，并确保它们开机自启。
接下来，添加GitLab的镜像源，并执行安装命令。安装完成后，进行一些配置，包括指定服务器IP、端口等。修改external_url和listen_port，确保端口未被占用。配置完成后，unity 框架 源码下载重置并启动GitLab服务。
安装配置完成后，可以通过网页访问GitLab。使用默认的root账户和密码登录后，可以创建项目、用户和组，并进行管理。
在遇到常见问题，如忘记用户密码时，可以使用命令进行密码更新。对于普通用户注册问题，由于GitLab服务安装后通常不配置邮箱服务，可以使用root管理员账号创建用户，并设置密码。
Gitlab Cookie 反序列化漏洞研究
Gitlab Cookie 反序列化漏洞研究
在hackthebox的Laboratory靶机中，我遇到了一个利用Gitlab任意文件读取漏洞进行getshell的过程。尽管很多walkthrough提到了漏洞利用，但对getshell原理的解释不够详尽，这让我感到疑惑。因此，我决定深入探究。 漏洞源头始于Hackone上William Bowling (vakzz)的报告，指出UploadsRewriter函数的文件名验证漏洞，导致了任意文件读取。Gitlab最初评估该漏洞价值美元。然而，作者发现当cookies_serializer默认设置为：hybrid时，可能导致远程命令执行漏洞。他提供了一个代码示例，但对不熟悉Ruby的我来说，操作起来并不顺利。 作者通过发送数据包执行命令，结果在带有Gitlab的rails console上实现了命令执行。阅读作者的校园小程序源码PDF文档，虽然英文有些吃力，但了解到cookie被分为两部分，第一部分是Base编码的session哈希，第二部分是用secret_token生成的签名。关键在于，客户端控制的cookie允许用户输入自定义序列化对象，只要能伪造签名，攻击者就能在服务器上执行任意代码。而secret_token的存在使这一过程变得可能，但其安全性取决于开发者是否妥善保管。 在Metasploit源码中，我寻找关于Gitlab cookie反序列化攻击的资料，但未果。最终，我直接分析了msf模块multi/http/gitlab_file_read_rce的执行过程。源码中的exploit函数和build_payload函数构建了反弹shell。经过多次测试和解码，我提炼出了Ruby生成payload的简化脚本，最终成功构造了能够执行命令的Cookie。 通过这次研究，我深刻认识到技术能力的不足耗费了大量时间。经过两天两夜的努力，我才解决了这个问题，也更加理解了Gitlab Cookie反序列化漏洞的原理。开源协议专题(七)：BSD、MIT、ApacheL
上篇文章介绍了 GPL、MPL、LGPL ，本文继续介绍剩下的三个许可证 BSD、MIT、Apache License。
四、BSD 许可证：
1、模版堂整站源码概念：
BSD 许可协议，即 Berkeley Software Distribution license 的简称，是由加州大学伯克利分校发布并维护的开源软件许可证。BSD许可证是自由软件中使用最广泛的许可协议之一。
2、两个概念：
BSD：人们常说的BSD，指的是 Berkeley Software Distribution，即伯克利软件套件，是加州大学伯克利分校在AT&T贝尔实验室的Unix操作系统基础上，开发打包的操作系统及相关软件套件。
BSD许可协议：BSD套件遵循某种开源许可证的方式发布，这种许许可证因此而得名，被叫做 BSD许可证。
3、BSD协议特点：
BSD开源协议是一个给予使用者很大自由的协议，可以自由的使用、修改源代码，也可以将修改后的代码作为开源或者专有软件再发布。
4、版本演进历史：
BSD协议的初稿内含有一项额外的条款，要求所有从以BSD许可证授权的软件派生著作，都必须要包含一段文字以交代源代码的来源。该条文列于原BSD许可证的第三条。
GNU项目将这个称为“令人感到不舒服的BSD交代条款”，GNU工程认为存在两个问题：
应自由软件基金会和GNU计划的发起者斯托曼的请求，年7月日，伯克利技术许可办公室的主管 William Hoskins 删除了BSD许可证的第三条。从此以后，自由软件作者就可以方便地采用BSD许可证下的软件，从而跟GPL下的作品融合。
原来的许可证有时被称为“BSD-old”（老BSD）或“4-clause BSD”（四句版BSD），当前的BSD许可证有的被称为“BSD-new”（新BSD）、“revised BSD”（修订的BSD）或“3-clause BSD”（三句版BSD）。
5、协议分析：
当发布使用了BSD协议的代码或以BSD协议代码为基础做二次开发自己的产品时，需满足以下三个条件：
BSD协议鼓励项目代码共享，但需要尊重作者的著作权。BSD协议由于允许使用者修改和重新发布代码，也允许在BSD代码上开发商业软件发布和销售，因此是对商业集成很友好的协议。
很多公司在选用开源产品的时候都首选BSD协议，因为可以完全控制这些第三方的代码，在必要的时候可以修改或者二次开发。遵守BSD 协议的软件，允许用作商业用途，甚至可按照专属许可证进行再发布。
五、MIT 协议：
1、概念：
MIT 许可协议：即 The MIT License，该许可协议之名源自麻省理工学院（Massachusetts Institute of Technology, MIT），又称“X许可协议”（X License）或“X许可协议”（X License）。
2、版本演进历史：
，由自麻省理工学院(MIT)发布。
3、协议特点：
MIT许可协议是许多软件许可条款中被广泛使用的其中一种。与其他常见的软件许可协议（如GPL、LGPL、BSD）相比，MIT是相对宽松的软件许可协议，赋予软件被许可人更大的权利与更少的限制。
4、协议分析：
5、其他重要特性：
有许多团体均采用MIT许可证，例如著名的SSH连线软件PuTTY与X窗口系统、Expat、Mono开发平台库、Ruby on Rails、Lua等等也都采用MIT许可协议。
六、Apache 许可协议：
1、概念：
Apache许可证，即 Apache License，是一个由Apache软件基金会(ASF)发布的自由软件许可证。
Apache许可证最初为 Apache Web 服务器而撰写，Apache许可证在Apache社区内外被广泛使用；Apache基金会下属所有项目都使用Apache许可证；许多非Apache基金会项目也使用了Apache许可证。
官网： apache.org/licenses/
2、版本演进历史：
Apache License 1.0，年发布。
apache.org/licenses/LIC...
Apache License 1.1，年发布。 apache.org/licenses/LIC...
Apache License 2.0，年发布。 apache.org/licenses/LIC...
3、协议要求：
Apache许可证，具体要求如下：
对所有未修改的部分应用相同的许可证，并且在每个许可文件中，必须保留再分发代码中的任何原始著作权、专利、商标和归属通知(不需要包括任何部分的派生作品)；
在每个更改的许可文件中，都必须添加一条通知，说明对该文件进行了更改。
不强制要求派生和修改产物使用相同的许可证进行发布。
4、协议分析说明：
如果声明文本文件是作为原始作品发布的一部分，则派生作品必须包含该通知文本文件的可读副本，可以是文档或显示在软件中。
声明文件的内容不会修改许可证，因为它们仅用于提供信息，并且可以在许可证文本中添加更多属性声明，前提是这些声明不能被理解为修改许可证。修改可能有适当的著作权声明，并可能为修改提供不同的许可条款。
七、许可证的对比与总结：
对于一个开源协议来说，规定得太宽松，会导致作者丧失对开源软件的很多权利，规定的太严格，又不利于开源软件的使用和传播。用一张图总结以上介绍的几个主流开源许可证的权限宽松情况：
我们在选择使用开源软件、或者准备开源自己的软件时，一定要明白自己的用途，选择合适的许可证。希望我们站在巨人肩膀上前行的同时，不忘用法律的武器来为我们自身保驾护航。
GitLab ARM源码在信创统信UOS下的搭建
GitLab是一个基于Ruby on Rails语言开发的开源应用，提供私有化的Git项目仓库，可通过Web界面进行访问和管理。GitLab官方提供了多种安装方式，包括通过操作系统软件源安装、Docker容器部署以及源代码自编译安装。然而，GitLab官方构建的软件包和镜像主要针对X架构，并未提供针对ARMv8的版本。UOS操作系统支持多种CPU架构（AMD、ARM、MIPS、SW）和六种国产CPU平台（鲲鹏、龙芯、申威、海光、兆芯、飞腾）以及Intel/AMD的主流CPU，UOSV基于Debian stable，内核为4.，支持多种架构。由于GitLab官方Omnibus安装包并未支持arm架构，因此需要通过源码编译来安装GitLab-ce .1-stable在UOSV arm架构上。
在部署GitLab-ce .1-stable之前，首先需要搭建编译环境，包括Ruby 2.7.4、redis 6.2.4、git 2..0、Go:.、Postgres: 、Node: .x、Nginx:1..1。编译过程较为平顺，但安装Ruby、Node和Go时需要注意选择国内镜像源以确保顺利编译。GitLab-ce:-1-stable版本要求Git2..x或以上版本，推荐使用Gitaly提供的git版本。UOSV 版本若选择调试工具包，则系统自带的git版本不符合要求，需要手动安装Gitaly所提供的git版本，确保版本满足GitLab要求。安装完成后，系统会显示版本为2..0，满足要求。此外，还需安装GraphicsMagick支持GitLab引入的自定义图标功能，以及安装Postfix邮件服务器和exiftool以支持GitLab Workhorse功能。Ruby的安装也非常重要，更换国内Ruby Gem源能够提高编译过程的稳定性。
在完成编译环境搭建后，需为GitLab创建一个名为git的用户。GitLab .1及以后版本仅支持PostgreSQL数据库，GitLab-ce .1-stable需要PostgreSQL 或以上版本，并且需要pg_trgm扩展和btree_gist扩展。GitLab .0及以后版本要求Redis版本4.0或以上，推荐使用6.0或以上版本。部署GitLab-ce .1-stable需要编译三个部分：gitLab核心代码、gitlab-shell和GitLab-Workhorse。编译完成后，主要目录结构会根据部署环境进行相应调整。
配置GitLab的各个组件时，需要将源码配置调整为已搭建环境的配置。主要修改数据库配置为已安装的PostgreSQL 版本。安装过程中可能会遇到一些小问题，如使用sudo执行某些命令时的超时错误。解决这类问题通常需要检查和调整环境变量，确保git账号的环境变量能够正常工作。例如，通过修改/etc/sudoers文件，确保在执行sudo命令时保留所需的环境变量，如GOPROXY。安装完成后，GitLab及其环境应已正确配置，系统架构识别为arm，GitLab版本为.1，redis版本未读取但不影响使用。至此，GitLab在UOSV arm架构上成功部署完毕。
