NTP users are strongly urged to take immediate action to ensure that their NTP daemons are not susceptible to being used in distributed denial-of-service (DDoS) attacks. Please also take this opportunity to defeat denial-of-service attacks by implementing Ingress and Egress filtering through BCP38.
ntp-4.2.8p15 was released on 23 June 2020. It addresses 1 medium-severity security issue in ntpd, and provides 13 non-security bugfixes over 4.2.8p13.
Are you using Autokey in production? If so, please contact Harlan - he's got some questions for you.
Related Topics: MaintainerIssues
, Bug #2548
, Bug #2512
, Bug #2216
, Bug #2053
, Bug #1687
, Bug #1365
, Bug #1106
, Bug #1055
Harlan's original Bugzilla wishlist
- I would like to see something like what issuezilla has, similar to "what" and "how important". With this in mind, I'd like to see the "what" category include:
- version (this filed could probably use an associated "date")
- unresolved means it's a target milestone
- resolved means it's a released milestone
- Issues scheduled for a particular release would automatically appear in the dependency chain for that release.
I now look at "Severity" as "how important is this to the reporter?" and "Priority" is "how important is it to the Project?". I notice pros and cons to Priority being generally visible, and it almost certainly should not be editable by users. There may be cases where an issue is not in the least "severe" but for some reason (like contractual obligation or to get a sale) it has a high priority. I suspect I'd like to see better documentation of some of these seemingly bizarre cases.
- As a release engineer for a particular milestone I want all "issues" that are slated for that milestone to also appear as "my bugs", in addition to being on the "my bugs" list for the assigned person.
With these features it should be pretty easy to come up with a mostly automated page that looks like subversion's project_status.html page. OK, it looks like that page is no longer available.
- The Release Engineer should be the only one to mark a bug as CLOSED
- The Release Engineer should be the only one to mark a bug as FIXED
Different products may have different needs in this area.
for information about how we've been using Bugzilla to help us with workflow.
For "code release" products, the Release Engineer needs to know when a developer has finished with a patch, so their development repo can be pulled in to the release repo. We do that via the RESOLVED/READY state.
I'd like to start getting code reviews built in to this process as well, but right now we don't have enough developers to do code reviews.
I run a custom report to show me READY bugs, and I take those, do some build testing on them, then integrate them into the distribution. I mark the bug as RESOLVED/FIXED, with a note to the reporter to please check the upcoming release and mark the bug as VERIFIED or IN_PROGRESS, as appropriate. We don't have a QA team to handle those checks.
There is no need for this workflow in non-code products.
Steve implemented a Security category recently - I can see some of the pros/cons of this approach, and I don't have a full grasp of the ramifications.
Anyway, from my POV when a developer marks a bug as READY the owner should change to me, because the developer may not care about anything else unless the bug is "reopened".
We need to be careful about plaintext email updates to security-flagged bugs.
We need to be careful and aware of what happens when a security bug is opened, where email is sent, what our IRC
bot reports, what people who explicitly go to that bug number can see, etc.
In the old days we did not have a "security issues" component in the NTP Product. If we had a group restriction that controlled the information flow.
The choice for restricting security bugs via group restriction or using a separate component affects whether or not the default owner of the component will know about the issue (by default).
- There is a SecureMail extension to Bugzilla which allows you to mark a group as "requiring secure mail". Then, all email for bugs in that group are either sent encrypted (S/MIME or GPG supported) or you just get an email which says "Bug X changed" and nothing else. Mozilla uses this for our security bugs.
Keeping the data from the bot would be as simple as making sure that either:
* the account to which the bot subscribes is not a member of the security group; or
* the account to which the bot subscribes does not have an encryption key configured; or
* the bot doesn't know how to decrypt mail or doesn't have access to the decryption key.
People who explicitly visit a bug number they can't see get a "You are not allowed to see bug XXXX" message.
I'm very happy to expand more on how Mozilla handles security bugs in Bugzilla, but it works very well for us. -- GervaseMarkham
- 17 Nov 2014