Merge branch 'main' into update-docs-on-tokens

Author: beckermr

src/maintainer/knowledge_base.rst

@@ -1566,3 +1566,16 @@ Sometimes, you might get a migration PR for your package that you don’t want t
 If you close the PR, it makes the bot think that another PR implementing the migration is merged instead, letting the migration continue iterating on the graph; however, the downstream dependents fail because the parent (the one we closed the PR of) didn’t really get rebuilt.
 Another reason why it is good to keep the PR open or in draft status is that people might help with it if they want in the future.
 
+Security considerations for conda-forge builds
+==============================================
+
+All ``conda-forge`` packages are built by strangers on the internet on public cloud infrastructure from source code you likely have not inspected, so you should not use ``conda-forge`` packages if you or your team require a high level of security. 
+You are also free to download recipes and rebuild them yourself, if you would like at least that much oversight. However, many people use ``conda-forge`` all the time with no issues and here are some things that ``conda-forge`` does to help with security in some ways:
+
+1. `Sources <https://conda-forge.org/docs/maintainer/adding_pkgs.html#source>`_ (where you specify where the package's source code is coming from) can be pulled from GitHub, PyPI, or other sources and sha256 hashes are always used, so moving of tags or uploading of new sdists can not cause automatic package rebuilds.
+   Also, once packages are accepted and made into feedstocks, only the maintainers of that feedstock have the right to merge PRs made to that feedstock.
+2. Each feedstock can only upload packages for that feedstock. This is enforced by using a cf-staging channel where builds are first sent. 
+   A bot then assesses that the submitting feedstock has permission to build the package it has submitted, and only then will it relay the build to the conda-forge channel.
+   This helps mitigate against a bad actor gaining access to an inconspicuous feedstock and then trying to push a build with malicious code into essential infrastructure packages (e.g., OpenSSL or Python).
+3. We have `artifact-validation <https://github.com/conda-forge/artifact-validation>`__ for validating all the ``conda-forge`` artifacts before they are uploaded to ``anaconda.org``. This validation looks for various security-related items, such as artifacts that overwrite key pieces of certain packages.
+4. We have a dedicated `Security and Systems Sub-Team <https://conda-forge.org/docs/orga/subteams.html?highlight=security+team#security-and-systems-sub-team>`__ who works hard towards making sure to secure and maintain appropriate access to the credentials and services/systems used by ``conda-forge``.

src/user/announcements.rst

@@ -8,6 +8,32 @@ Our announcements are published to an RSS feed `here <https://conda-forge.org/do
 2022
 ----
 
+2022-08-17: Dropping PyPy 3.7
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Conda-forge has supported PyPy since almost 2.5 years now, and the initial
+PyPy 3.7 builds have been superseded in almost all aspects by the newer builds
+for 3.8 & 3.9. We are therefore dropping PyPy 3.7 as a supported python version,
+and will keep focusing on the more contemporary PyPy builds.
+
+2022-08-11: Moving to Visual Studio toolchain vc142
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Microsoft has deprecated the Visual Studio (VS) 2017 compiler and removed it
+from all the CI they control (notably Azure Pipelines & Github Actions).
+This means that the default toolchain (== C/C++ compiler, linker, standard
+libraries, and related utilities) of that VS version - vc141 - is getting less
+and less use in upstream libraries (because public hosted CI doesn't use it
+anymore by default), and therefore support for it is bitrotting
+at an accelerating pace. We are therefore
+`planning <https://github.com/conda-forge/conda-forge-pinning-feedstock/pull/3167>`_
+to move our toolchain on windows to vc142 (the default in VS2019) in two weeks,
+on 2022-08-25.
+
+This will not affect you as a general user of conda-forge packages on windows;
+the only impact is that if you are locally compiling against artefacts produced
+by conda-forge and are still using VS2017 yourself, you will need to upgrade your
+compiler (VS2019 is a drop-in replacement & ABI-compatible).
 
 2022-07-22: Azure OSX VM Image Bumped to Version 11
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^