Skip to content
This repository has been archived by the owner on Jul 25, 2023. It is now read-only.

Issues: shieldworks/aegis

167 Open 253 Closed
167 Open 253 Closed
Author
Filter by author
Loading
Label
Filter by label
Loading
Use alt + click/return to exclude labels
or ⇧ + click/return for logical OR
Projects
Filter by project
Loading
Milestones
Filter by milestone
Loading
Assignee
Filter by who’s assigned
Sort
Sort by
Newest Oldest Most commented Least commented Recently updated Least recently updated Best match
Most reactions
👍 👎 😄 🎉 😕 ❤️ 🚀 👀

Issues list

Update documentation about fips compliance important
#483 opened Jul 19, 2023 by v0lkan
@v0lkan
a command line utility to do replacements on any file talking to Aegis Safe enhancement New feature or request
#482 opened Jul 18, 2023 by v0lkan v0.19.0
Test aegis on a kind cluster
#480 opened Jul 14, 2023 by v0lkan
@v0lkan
add some badges to the readme
#475 opened Jul 6, 2023 by v0lkan
1
Sentinel is getting too crowded with flags; maybe it’s time to introduce subcommands:
#474 opened Jul 6, 2023 by v0lkan
1
Add sentinel the ability to randomly generate key for the "manual insertion" mode. — Sentinel shall require a public key, and encrypt the response with that public key before delivering it (for added security) — the owner of the private key then can decrypt the result — we can also write a helper binary for that
#473 opened Jul 6, 2023 by v0lkan
1
All medium and higher severity exploitable vulnerabilities discovered with dynamic code analysis MUST be fixed in a timely way after they are confirmed. openssf
#472 opened Jul 5, 2023 by v0lkan
It is SUGGESTED that the project use a configuration for at least some dynamic analysis (such as testing or fuzzing) which enables many assertions. In many cases these assertions should not be enabled in production builds. openssf
#471 opened Jul 5, 2023 by v0lkan
It is SUGGESTED that at least one dynamic analysis tool be applied to any proposed major production release of the software before its release. openssf
#470 opened Jul 5, 2023 by v0lkan
It is SUGGESTED that static source code analysis occur on every commit or at least daily. \ openssf
#469 opened Jul 5, 2023 by v0lkan
All medium and higher severity exploitable vulnerabilities discovered with static code analysis MUST be fixed in a timely way after they are confirmed. openssf
#468 opened Jul 5, 2023 by v0lkan
The public repositories MUST NOT leak a valid private credential (e.g., a working password or private key) that is intended to limit public access. openssf
#467 opened Jul 5, 2023 by v0lkan
Projects SHOULD fix all critical vulnerabilities rapidly after they are reported. openssf
#466 opened Jul 5, 2023 by v0lkan
There MUST be no unpatched vulnerabilities of medium or higher severity that have been publicly known for more than 60 days. openssf
#465 opened Jul 5, 2023 by v0lkan
The security mechanisms within the software produced by the project MUST generate all cryptographic keys and nonces using a cryptographically secure random number generator, and MUST NOT do so using generators that are cryptographically insecure. openssf
#464 opened Jul 5, 2023 by v0lkan
The security mechanisms within the software produced by the project SHOULD implement perfect forward secrecy for key agreement protocols so a session key derived from a set of long-term keys cannot be compromised if one of the long-term keys is compromised in the future. openssf
#463 opened Jul 5, 2023 by v0lkan
At least one of the project's primary developers MUST know of common kinds of errors that lead to vulnerabilities in this kind of software, as well as at least one method to counter or mitigate each of them. openssf
#462 opened Jul 5, 2023 by v0lkan
The security mechanisms within the software produced by the project MUST use default keylengths that at least meet the NIST minimum requirements through the year 2030 (as stated in 2012). It MUST be possible to configure the software so that smaller keylengths are completely disabled openssf
#461 opened Jul 5, 2023 by v0lkan
The project MUST have at least one primary developer who knows how to design secure software. (See ‘details’ for the exact requirements.) openssf
#460 opened Jul 5, 2023 by v0lkan
It is SUGGESTED that this policy on adding tests (see test_policy) be documented in the instructions for change proposals. openssf
#459 opened Jul 5, 2023 by v0lkan
The project MUST have evidence that the test_policy for adding tests has been adhered to in the most recent major changes to the software produced by the project. openssf
#458 opened Jul 5, 2023 by v0lkan
The project MUST have a general policy (formal or not) that as major new functionality is added to the software produced by the project, tests of that functionality should be added to an automated test suite. openssf
#457 opened Jul 5, 2023 by v0lkan
It is SUGGESTED that the project implement continuous integration (where new or changed code is frequently integrated into a central code repository and automated tests are run on the result). openssf
#456 opened Jul 5, 2023 by v0lkan
A test suite SHOULD be invocable in a standard way for that language. openssf
#455 opened Jul 5, 2023 by v0lkan
The project MUST use at least one automated test suite that is publicly released as FLOSS (this test suite may be maintained as a separate FLOSS project). The project MUST clearly show or document how to run the test suite(s) (e.g., via a continuous integration (CI) script or via documentation in files such as BUILD.md, README.md, or CONTRIBUTING.md). openssf
#454 opened Jul 5, 2023 by v0lkan
ProTip! Mix and match filters to narrow down what you’re looking for.