See also: disclosure
This page is designed to teach folks who may not be familiar with security what the generally accepted procedures are, and why they exist.
When a user or security researcher submits a bug to a maintainer of an open-source project, there are a number of factors that determine the proper course of action. The most basic is who is known to consume the software. If all your users obtain the code directly from your site, do not modify it, and are not known to redistribute it, it is probably OK to simply put a note in the next release that you “fixed a security issue in blah” - and promptly notify your users of the availability and importance of this new release.
However, if your package is redistributed by others, such an action is considered impolite, as it requires those redistributing to scramble to fix their version. Much better would be to give them a heads-up a bit before your release and coordinate with them so all affected distributions of your software can be fixed at the same time. That way, all users can obtain a fix as soon as the issue is public (and thus, ready for the black hats to start abusing). Open-source packages can be consumed and redistributed by a large number of individuals and companies, and contacting them all can be difficult. This is where security-related mailing lists come in.
If the vulnerability report was sent through a non-public channel (though not necessarily a secure one), the preferred method of contact is the vendor-sec mailing list, which is restricted to the security-team members of various open-source vendors such as Red Hat, Ubuntu, Debian, Gentoo, *BSD, etc.
If the report was sent to a public location, such as mailing list, public bug tracker, etc., the preferred method of contact is the oss-security mailing list, which is the counterpart to this wiki. This list should only be used if the issue is already public! This list is comprised of many of the same members as vendor-sec, plus members of the greater OSS community who are known to fruitfully participate in security-related discussions.
Regardless of which list is used, folks on-list will coordinate with you to get a fix for the issue (if one does not already exist), send the fix to everyone who needs to coordinate the public release of the information, obtain a CVE identifier, and set a public disclosure date for “embargoed” issues. Before the embargo is expired, the members of the list will fix their versions of your software. They will publish those fixes on or after the expiration of the embargo. This process also gives the security experts time to ensure that the fix is complete, and that duplicate or similar issues don't lurk in any other code. On the day the embargo ends, you should publish a new stable version with the agreed-upon fix, mentioning in the change log and release announcement the relevant CVE identifier.
If you absolutely have to make a release before the embargo ends, you may publish it during the embargo either without the security fix or with the fix but no mention of any security-related impact. In general, the latter is discouraged as many source code fixes are informative enough for a potential attacker even when no description is provided.