遵循以下最佳实践的项目将能够自愿的自我认证,并显示他们已经实现了核心基础设施计划(OpenSSF)徽章。 显示详细资料
[](https://www.bestpractices.dev/projects/374)
<a href="https://www.bestpractices.dev/projects/374"><img src="https://www.bestpractices.dev/projects/374/badge"></a>
Xen Project is a Linux Foundation Collaborative Project that develops the Xen Hypervisor and related virtualization technologies. The Xen Hypervisor is a leading virtualization platform that is powering some of the largest clouds in production today, such as Amazon Web Services, Rackspace Public Cloud, Alibaba Cloud (Aliyun) and many hosting services. It also fosters the creation of lightweight Unikernel systems with the Mirage OS incubator project, as well as many independent efforts which use our hypervisor as a base for their work.
https://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches
https://wiki.xenproject.org/wiki/Xen_Bug_Management_Interface
Many third parties provide packages (e.g., .deb for apt-get, .rpm). Since Xen is operating system like, installation is in general different than application software.
We do not yet have a documented policy. A formal policy was discussed (but not yet agreed) that requires all supported features to be automatically tested by OSSTEST, XTF, a 3rd party test system or manually with test reports sent in for RCs. We have not yet fully formalised and documented this policy, as some areas such as 3rd party and manual test reports cannot currently be automatically submitted and checked without manual intervention. However, there are logistical challenges to enforcing and correctly documenting such a policy, which have not yet been fully resolved.
We compile with -Wall -Wextra to turn on as many warnings as possible
We don't provide cryptographic libraries or facilities. The Xen hypervisor itself doesn't do any cryptography.
We do not use HTTP as an RPC transport. The toolstack software uses cryptography for migration, but it just uses whatever ssh you have as a transport (by default). We do support VNC, which has some encryption features. The encryption is entirely done by qemu using TLS.
After checking with the Linux Foundation, we were advised that we do not need to verify such choices for upstreams we depend on. In our case, we use QEMU which uses TLS for VNC.
After checking with the Linux Foundation, we were advised that we do not need to verify such choices for upstreams we depend on. In our case, we use QEMU which uses TLS for VNC. However, this doesn't seem like it could work given TLS's security model: the VNC server is the user's and it would have to get a cert somehow.
We do not use HTTP as an RPC transport.
This is rather vague and needs more information to identify what is acceptable and what is not.
警告:需要更长的理由。
Vendors such as Citrix, Oracle and SUSE, run their own test suites which for example in the case of Citrix who runs XenRT includes fuzzing functionality on XEN PROJECT release candidates. The project also runs AFL on portions of the code base as part of its test infrastructure.
后退