ICODE-ADC/lammps
4
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

update explanations for version updates in security policy file

Browse Source
This commit is contained in:
Axel Kohlmeyer
2022-09-25 10:37:59 -04:00
parent af3da50bda
commit e38d7cf192
1 changed files with 19 additions and 11 deletions
Download Patch File Download Diff File Expand all files Collapse all files

30
SECURITY.md
View File

@ -14,14 +14,14 @@ and tested by the LAMMPS developers, so it is easy to import bad
behavior from calling functions in one of those libraries.
Thus is is quite easy to crash LAMMPS through malicious input and do all
kinds of filesystem manipulations. And because of that LAMMPS should
kinds of file system manipulations. And because of that LAMMPS should
**NEVER** be compiled or **run** as superuser, either from a "root" or
"administrator" account directly or indirectly via "sudo" or "su".
Therefore what could be seen as a security vulnerability is usually
either a user mistake or a bug in the code. Bugs can be reported in
the LAMMPS project
[issue tracker on GitHub](https://github.com/lammps/lammps/issues).
either a user mistake or a bug in the code. Bugs can be reported in the
LAMMPS project [issue tracker on
GitHub](https://github.com/lammps/lammps/issues).
To mitigate issues with using homoglyphs or bidirectional reordering in
unicode, which have been demonstrated as a vector to obfuscate and hide
@ -30,10 +30,18 @@ for unicode characters and only all-ASCII source code is accepted.
# Version Updates
LAMMPS follows continuous release development model. We aim to keep all
release versions (stable or patch) fully functional and employ a variety
of automatic testing procedures to detect failures of existing
functionality from adding new features before releases are made. Thus
bugfixes and updates are only integrated into the current development
branch and thus the next (patch) release and users are recommended to
update regularly.
LAMMPS follows continuous release development model. We aim to keep to
keep the development version (develop branch) always fully functional
and employ a variety of automatic testing procedures to detect failures
of existing functionality from adding or modifying features. Most of
those tests are run on pull requests *before* merging to the development
branch. The develop branch is protected, so all changes *must* be
submitted as a pull request and thus cannot avoid the automated tests.
Additional tests are run *after* merging. Before releases are made
*all* tests must have cleared. Then a release tag is applied and the
release branch fast-forwarded to that tag. Bug fixes and updates are
applied to the current development branch and thus will be available in
the next (patch) release. For stable releases, selected bug fixes are
back-ported and occasionally published as update releases. There are
only updates to the latest stable release.