New Security Reporting and Disclosure policy for the AtoM project
134 views
Skip to first unread message
Dan Gillean
Aug 28, 2019, 2:54:29 PM8/28/19
to ICA-AtoM Users
Hello everyone!
If you would like to report a vulnerability or have a security concern regarding AtoM, please do not file a public issue in our GitHub repository or post about it in the AtoM user forum. Instead, please email a report to:
We will be better able to evaluate and respond to your report if it includes all the details needed for us to reproduce the issue locally. Please include the following information in your email:
In case you have not yet heard, we have just released AtoM 2.5.2, which includes a security patch for a regression that caused a vulnerability in AtoM. Details on this and all other fixes in the release can be found on the official 2.5.2 release page:
This security issue was discovered in part thanks to reports from our amazing community of users - thank you! Specifically, I would like to thank Thomas Misilo, Kenny Pierce, and Augusto Torres for helping to bring this regression to our attention.
In order to ensure that we have a safe and transparent procedure in place for handling security-related issues in the future, we have drafted a new Security Reporting and Disclosure policy for the AtoM project. The full details are stored with the code in the AtoM repository, here:
To help spread the word about this new policy, I'm including all the details found at the link above in this message, for reference.
Reporting a security vulnerability
The AtoM development team takes security seriously and will investigate all reported vulnerabilities. Thank you for your interest in helping!If you would like to report a vulnerability or have a security concern regarding AtoM, please do not file a public issue in our GitHub repository or post about it in the AtoM user forum. Instead, please email a report to:
We will be better able to evaluate and respond to your report if it includes all the details needed for us to reproduce the issue locally. Please include the following information in your email:
- The version of AtoM you are using
- Basic information about your installation environment, including PHP, MySQL, Elasticsearch, and operating system versions
- Steps to reproduce the issue
- The resulting error or vulnerability
- If there are any error logs related to the issue, please include the relevant parts as well
Your report will be acknowledged within 2 business days, and we’ll follow up with a more detailed response indicating the next steps we intend to take within 1 week.
If you haven’t received a reply to your submission after 5 business days of the original report, there are a couple steps you can take:
Any information you share with the AtoM development team as a part of this process will be kept confidential within the team. If we determine that the vulnerability is located upstream in one of the libraries or dependencies that AtoM uses, we may need to share some information about the report with the dependency’s core team - in this case, we will notify you before proceeding.
If the vulnerability is first reported by you, we will credit you with the discovery in the public disclosure, unless you tell us you would prefer to remain anonymous.
Disclosure policy
When the AtoM development team receives a security bug report, we will assign it to a primary handler. This person will coordinate the fix and release process, involving the following steps:
Supported versions
In the case of a confirmed security issue, we will add the fix to the most recent stable branch, and the development branch (prefaced by qa/ in our branch naming conventions. For more information on this, see this section of our wiki). If the severity of the issue is high, we may in some cases also backport the fix to the previous stable branch as well (e.g. stable/2.5.x, etc), so that community users running a legacy version have the option of adding the fix as a patch to their local installations. We will attempt to ensure that fixes, and/or a confirmed workaround that resolves the security issue, are available prior to disclosing any security issues publicly.
AtoM and security overview
AtoM’s security guidelines are available here:
AtoM also provides additional security measures via the administrative settings in the user interface - see:
To provide greater redundancy in the case of something going wrong, users may be interested in learning more about AtoM’s 2-site deployment model and replication script. For more information, see:
If you haven’t received a reply to your submission after 5 business days of the original report, there are a couple steps you can take:
- Email the AtoM Program Manager directly: d...@artefactual.com
- Join the AtoM user forum
Any information you share with the AtoM development team as a part of this process will be kept confidential within the team. If we determine that the vulnerability is located upstream in one of the libraries or dependencies that AtoM uses, we may need to share some information about the report with the dependency’s core team - in this case, we will notify you before proceeding.
If the vulnerability is first reported by you, we will credit you with the discovery in the public disclosure, unless you tell us you would prefer to remain anonymous.
Disclosure policy
When the AtoM development team receives a security bug report, we will assign it to a primary handler. This person will coordinate the fix and release process, involving the following steps:
- Confirm the problem and determine the affected versions;
- Audit code to find any similar potential problems;
- Prepare fixes for all releases still under maintenance. These fixes will be released as fast as possible.
Supported versions
In the case of a confirmed security issue, we will add the fix to the most recent stable branch, and the development branch (prefaced by qa/ in our branch naming conventions. For more information on this, see this section of our wiki). If the severity of the issue is high, we may in some cases also backport the fix to the previous stable branch as well (e.g. stable/2.5.x, etc), so that community users running a legacy version have the option of adding the fix as a patch to their local installations. We will attempt to ensure that fixes, and/or a confirmed workaround that resolves the security issue, are available prior to disclosing any security issues publicly.
AtoM and security overview
AtoM’s security guidelines are available here:
AtoM also provides additional security measures via the administrative settings in the user interface - see:
To provide greater redundancy in the case of something going wrong, users may be interested in learning more about AtoM’s 2-site deployment model and replication script. For more information, see:
- https://www.slideshare.net/accesstomemory/2-sitereplication-with-atom
- https://github.com/artefactual-labs/atom-replication
If you have discovered an issue in AtoM that is not related to a security vulnerability, we welcome your reports, either filed as issues in our GitHub code repository, or by posting about them in the AtoM user forum. Please see our CONTRIBUTING.md file for more information.
Thank you all! As always, feedback and questions are welcome!
Cheers,
Karl Goetz
Aug 28, 2019, 8:29:57 PM8/28/19
to ica-ato...@googlegroups.com
On Wed, 28 Aug 2019 14:54:13 -0400
Dan Gillean <d...@artefactual.com> wrote:
> Hello everyone!
>
Hi Dan,
> In order to ensure that we have a safe and transparent procedure in
> place for handling security-related issues in the future, we have
> drafted a new Security Reporting and Disclosure policy for the AtoM
> project. The full details are stored with the code in the AtoM
> repository, here:
>
> [...]
> repository or post about it in the AtoM user forum.* Instead, please
> email a report to:
>
> - secu...@artefactual.com
I'm not sure if accesstomemory.org mx's are used, but perhaps
also ensure security@ works on that domain if it is configured to
recieve mail.
thanks,
--
Karl Goetz
Technical Services Officer - eResearch, Information Technology Services
University of Tasmania & Tasmanian Partnership for Advanced Computing
Mail: University of Tasmania, Private Bag 69, Hobart, Tasmania 7001
Delivery: TT Flynn Street, Sandy Bay, Tasmania 7005
University of Tasmania Electronic Communications Policy (December, 2014).
This email is confidential, and is for the intended recipient only. Access, disclosure, copying, distribution, or reliance on any of it by anyone outside the intended recipient organisation is prohibited and may be a criminal offence. Please delete if obtained in error and email confirmation to the sender. The views expressed in this email are not necessarily the views of the University of Tasmania, unless clearly intended otherwise.
Dan Gillean <d...@artefactual.com> wrote:
> Hello everyone!
>
Hi Dan,
> In order to ensure that we have a safe and transparent procedure in
> place for handling security-related issues in the future, we have
> drafted a new Security Reporting and Disclosure policy for the AtoM
> project. The full details are stored with the code in the AtoM
> repository, here:
>
> If you would like to report a vulnerability or have a security concern
> regarding AtoM,* please do not file a public issue in our GitHub
> repository or post about it in the AtoM user forum.* Instead, please
> email a report to:
>
> - secu...@artefactual.com
I'm not sure if accesstomemory.org mx's are used, but perhaps
also ensure security@ works on that domain if it is configured to
recieve mail.
thanks,
--
Karl Goetz
Technical Services Officer - eResearch, Information Technology Services
University of Tasmania & Tasmanian Partnership for Advanced Computing
Mail: University of Tasmania, Private Bag 69, Hobart, Tasmania 7001
Delivery: TT Flynn Street, Sandy Bay, Tasmania 7005
University of Tasmania Electronic Communications Policy (December, 2014).
This email is confidential, and is for the intended recipient only. Access, disclosure, copying, distribution, or reliance on any of it by anyone outside the intended recipient organisation is prohibited and may be a criminal offence. Please delete if obtained in error and email confirmation to the sender. The views expressed in this email are not necessarily the views of the University of Tasmania, unless clearly intended otherwise.
Dan Gillean
Aug 29, 2019, 10:47:31 AM8/29/19
to ICA-AtoM Users
Hi Karl,
Thanks for your input! We had originally thought to make the address @accesstomemory.org, but it is not currently set up to receive mail, and in the interest of getting our policy out with the release, we went with the @artefactual domain. However, if it's possible for us to set up an alias or something that will redirect mail sent there to @artefactual, that would be a great idea! I'll ask our team about that possibility.
Cheers,
--
You received this message because you are subscribed to the Google Groups "AtoM Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ica-atom-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/20190829101601.17b46c8e%40minister.
Karl Goetz
Aug 29, 2019, 7:34:47 PM8/29/19
to ica-ato...@googlegroups.com
On Thu, 29 Aug 2019 10:47:19 -0400
Dan Gillean <d...@artefactual.com> wrote:
> Hi Karl,
>
> Thanks for your input! We had originally thought to make the address @
> http://accesstomemory.org,
Dan Gillean <d...@artefactual.com> wrote:
> Hi Karl,
>
> Thanks for your input! We had originally thought to make the address @
> but it is not currently set up to receive mail, and in the interest
> of getting our policy out with the release, we went with the
> @artefactual domain. However, if it's possible for us to set up an
> alias or something that will redirect mail sent there to
> @artefactual, that would be a great idea! I'll ask our team about
> that possibility.
Hi Dan,
> of getting our policy out with the release, we went with the
> @artefactual domain. However, if it's possible for us to set up an
> alias or something that will redirect mail sent there to
> @artefactual, that would be a great idea! I'll ask our team about
> that possibility.
GoDaddy (registrar of accesstomemory.org) should have some mail
managent to allow forwarding email for the domain, I don't recall off
hand if they will forward individual mail or everything but its a
starting point!
Dan Gillean
Sep 4, 2019, 4:31:12 PM9/4/19
to ICA-AtoM Users
Hi Karl,
Just a quick follow up to say that we've now set up mail forwarding - security@artefactual remains the primary account to use, but if users send an email to security@accesstomemory by accident, it will be forward to the correct inbox.
Thanks again for the great suggestion!
--
You received this message because you are subscribed to the Google Groups "AtoM Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ica-atom-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/20190830092036.6e461faa%40minister.
Karl Goetz
Sep 4, 2019, 9:26:47 PM9/4/19
to ica-ato...@googlegroups.com
On Wed, 4 Sep 2019 16:30:59 -0400
Dan Gillean <d...@artefactual.com> wrote:
Thanks Dan!
Karl.
> Hi Karl,
>
> Just a quick follow up to say that we've now set up mail forwarding -
> security@artefactual remains the primary account to use, but if users
> send an email to security@accesstomemory by accident, it will be
> forward to the correct inbox.
>
> Thanks again for the great suggestion!
>
> Dan Gillean, MAS, MLIS
> AtoM Program Manager
> Artefactual Systems, Inc
> <http://www.artefactual.com/>.
> 604-527-2056 @accesstomemory
> <https://twitter.com/accesstomemory>
Dan Gillean <d...@artefactual.com> wrote:
Thanks Dan!
Karl.
> Hi Karl,
>
> Just a quick follow up to say that we've now set up mail forwarding -
> security@artefactual remains the primary account to use, but if users
> send an email to security@accesstomemory by accident, it will be
> forward to the correct inbox.
>
> Thanks again for the great suggestion!
>
> Dan Gillean, MAS, MLIS
> AtoM Program Manager
> Artefactual Systems, Inc
> 604-527-2056 @accesstomemory
> <https://twitter.com/accesstomemory>
>
>
> On Thu, Aug 29, 2019 at 7:34 PM Karl Goetz <karl....@utas.edu.au>
> wrote:
>
> > On Thu, 29 Aug 2019 10:47:19 -0400
> > Dan Gillean <d...@artefactual.com> wrote:
> >
> > > Hi Karl,
> > >
> > > Thanks for your input! We had originally thought to make the
> > > address @
> > > http://accesstomemory.org,
> > > but it is not currently set up to receive mail, and in the
> > > interest of getting our policy out with the release, we went with
> > > the @artefactual domain. However, if it's possible for us to set
> > > up an alias or something that will redirect mail sent there to
> > > @artefactual, that would be a great idea! I'll ask our team about
> > > that possibility.
> >
>
> On Thu, Aug 29, 2019 at 7:34 PM Karl Goetz <karl....@utas.edu.au>
> wrote:
>
> > On Thu, 29 Aug 2019 10:47:19 -0400
> > Dan Gillean <d...@artefactual.com> wrote:
> >
> > > Hi Karl,
> > >
> > > Thanks for your input! We had originally thought to make the
> > > address @
> > > http://accesstomemory.org,
> > > but it is not currently set up to receive mail, and in the
> > > interest of getting our policy out with the release, we went with
> > > the @artefactual domain. However, if it's possible for us to set
> > > up an alias or something that will redirect mail sent there to
> > > @artefactual, that would be a great idea! I'll ask our team about
> > > that possibility.
> >
Reply all
Reply to author
Forward
0 new messages