This finally moves the patches into the db, which makes it a lot easier
to filter patches in the views.
It also adds the new way of categorising patches, which is assigning
them a CVSSv3 score.
For now, there are no public views to this, and the old static pages
remain. This is so we can backfill all existing security patches before
we make it public.
Sending from the submitters address runs afoul to DMARC and other
restrictions. Instead, send the email from a defined noreply address.
Instead, add the original submitter to both the Cc and the Reply-To
header, to make sure they receive followups.
Patch by Stephen, minor changes by Magnus
This workaround enabled a weaker password hasher to work with old
versions of the community authentication plugin. This was already
overridden in prod, but remove the old workaround completely from the
code so we don't accidentally re-enable it.
We want to use the noreply@ email address when sending out notifications
to addresses that have yet to be verified, since we can just ignore
bounces to those.
This creates Google, Github, Microsoft and Facebook login integrations.
Other providers can also be added if needed. Accounts still need to be
created in the community auth system, and will be automatically created
on first login, when the user also gets to pick a username. Once an
account exists, it will be matched on email address from the external
systems.
No methods are enabled by default, as they all require encryption keys
and identities configured in local_settings.py.
Review by Stephen Frost, Jonathan Katz and Daniel Gustafsson.
The ftp server can then submit a list (and structure) of which platforms
are supported for yum downloads, which can then later (in a separate
commit) be used to generate a nicer download for yum repo rpms.
We have so many users now that loading these forms take forever.
Instead, implement a textbox with autocomplete using django-selectable,
which will not load the whole list of users at once.
Per discussion from a long time ago, interactive docs aren't really
working out. The majority of submissions are either support questions
(which then get rejected because they cannot be answered in this
context) or pointing out docs incorrectnesses (which should be submitted
as a docs bug instead, so they can actually be fixed in the main
documentation).
Old references to /interactive/ will get redirected to /static/
automatically, and we expect to keep doing that for a long time (since
there are many links to them around the net).
The pwn module has never been used, as the pwn are simply sent to
-announce and nothing else. We've kept the code and model around for
doing it on the site for years now and it's unused, so let's remove it
to cut down on maintenance cost.
Move manage.py up one step, set up a new wsgi.py file, and adjust
relative paths that refer to other directories for the new project
layout that we need to use in django 1.8.
The queue used for varnish purges has so few entries that it's really
not worth paying the management overhead for skytools/pgq. Instead we
can use a very simple local deamon using LISTEN/NOTIFY to fire them off.
Now include a proper nagios plugin in this package, so we can get rid
of the not-very-nice munin plugin currently used in the deployment.
The idea is a git repository hook will send a POST to this URL, which
will drop a trigger file somewhere. A cronjob (or inotify listener if
we want to be really fancy sometiem in the future) will pick up that
cronjob and run the update script. The goal being to shorten the time
required to process an update.
Basically, user generated email (bug report form) will be sent to the mail
frontends for antispam. Any errors generated there will be ignored and
the mails "dropped on the floor". Other emails keep entering the system
through localhost and delivered there.
Import the code from the PostgreSQL Europe website to handle this, since it's
well proven by now.
Any points that send email now just write them to the database using the
functions in queuedmail.util. This means we can now submit notification
emails and such things within transactions and have them properly roll bcak
if something goes wrong (so no more incorrect notifications when there is
a database error).
These emails are picked up by a cronjob that runs frequently (typically
once per minute or once every 2 minutes) that submits them to the local
mailserver. By doing it out of line, this gives us a much better way of
dealing with cases where mail delivery is really slow.
The submission from the cronjob is now done with smtp to localhost instead
of opening a pipe to the sendmail command - though this should have no
major effects on anything.
This also removes the setting SUPPRESS_NOTIFICATIONS, as no notifications
are actually ever sent unless the cronjob is run. On development systems
they will just go into the queuedmail table, and can be deleted from there.
This will allow us to increase the cache times in the browser for our
CSS, which almost never changes.
Enables a new value to be used in templates, {{gitrev}}, which can be
used to bust pretty much any URL. We could do this for all the images
in the templates as well, but since most of them almost never change,
we'll just enable it manually for each individual image as it becomes
necessray - or just use a ?1, ?2 etc for those.
Enabled by default for CSS and JavaScript links, since those are much
more likely to be changed without having the URL changed.
Cache times aren't increased yet - we'll do that later one we're sure
that all existing caches are expired first.
This is required if the queue is dropped and recreated in pgq as it
gets a new id, which needs to be used when viewing the current status
of the queue in the admin interface.
Instead of having to update this list manually in multiple places when
releasing new versions, just take the information out of the database
where it has to be anyway.
Fixes#90Closes#93
Also make the code automatically pick up wich PDF files exist in the
static checkout, and auto-detect their size, both A4 and US sizes. This
removes yet one more manual step, yay!
Fixes#163
This is required for the old style community auth system that is still
in use by the commitfest app. Once that has been retired or upgraded,
this patch should be reverted.
Existing passwords are automatically converted once the user logs in to
the main website once.
The new archives has a http api - use that one for searching instead
of directly talking to the database.
With the new API, we always fetch the complete search results (still
capped server-side at 1000 items), and store them locally in memcached
for 10 minutes. That way, paging will only hit the local memcached and
not the remote http api *or* the SQL api.
Most of these forms look pretty benign, but the user profile form, which
includes an SSH key field, certainly needs to be protected.
The survey form is unprotected because it's served over insecure HTTP
and the Varnish proxy strips cookies, which is required by the builtin
CSRF protection.
Marti Raudsepp
We want an API for this so they end up in the queue with all the other
requests, and get delivered to all our frontends without needing each node
to know about which frontends exist.
This increases session security, obviously... It will also break local development
installs, which will have to add the two rows that this patch adds to the
documentation.
Previously this had to be rsynced outside of the website. By allowing the
upload here, and automatically purging the data from varnish, we will reach
"almost instant" updates of the ftp site structure on the web.
This makes it possible to render the search results on the main engine.
We still run the query on the seprate search server, so once has to be
configured in settings_local.py with the key SEARCH_DSN (standard
PostgreSQL/psycopg2 connection string)
the fact that when pages are served through Varnish, the request will come
from the Varnish server and not from the client.
Create a /system_information page that shows some information about the
connection to help diagnose how the caches work.
of the RSS feed. (Which will receive a new URL now that it lives in the
actual app and not in with the static files, so a redirect will be needed
there).
on the ftp server, instead of crawling the directoreis directly. This
removes the requirement to sync almost 10Gb worth of ftp site onto the
web server...
The pickle file for this is currently around 1Mb, so it's not a huge
burden on the server. If it grows larger in the future, we may want to
re-think this and split it up, or put it in a database format or something
like that.
