Pyramid 1.10.4 released

[Michael Merickel]

Hey folks, I just released 1.10.4. This simply fixes a performance regression introduced in 1.10.3 related to the view_config decorator.

Check the "What's New in Pyramid 1.10" for more information about 1.10:

https://docs.pylonsproject.org/projects/pyramid/en/1.10-branch/whatsnew-1.10.html

As always, please submit any issues on our issue tracker:

https://github.com/Pylons/pyramid/issues

Thanks!

- Pyramid core developers

[Aritz Sanchez]

Hello,

I am not sure if I should post this question here and apologise if I should have done it somewhere else instead.

I work for a Cyber Security company and we are evaluating the possibility of using Pyramid to develop part of our upcoming products. Pyramid seems to be meet our needs, and I have a few questions that would help us with the choice:

1.  I read that contributors should use the e-mail address pylons-proj...@googlegroups.com to report security issues found in any Pylons product.

    a. Is there any dedicated channel for releasing security advisories/announcements?

    b. Do you report CVE’s found in the Pylons products via NVD?

2. As far as I see, you maintain two stable versions: the most recent major release and the previous release. Currently, Pyramid 1.10.x and 1.9.x. If I understand it correctly, as soon as a new major version is released, the oldest of the two previous stable versions is no longer maintained? E.g., when Pyramid 2.0 is released (I guess it is going to be this year), 1.9.x will no longer be maintained. Is that so? (An approximate period of two years)

3. Do you backport security fixes to stale versions (e.g. 1.8.x, 1.7.x, …), or should users try to migrate to the newest releases as soon as possible?

 

I apologise again if I should have posted my message somewhere else and would really appreciate if you could point out the right place to do it instead.

 

Thanks in advance for your help.

 

Best regards,

Aritz Sanchez

[Steve Piercy]

Thank you for asking the questions. You've asked a couple of
questions for which we have not yet established and published
clear procedures, so we'll need to update our policies.

https://pylonsproject.org/community-support.html

I think we've just assumed what are best practices without
defining our procedures, but I'll defer to our more experienced
security issue response team members.


On 5/10/19 at 3:08 AM, asan...@phoenixcontact.com (Aritz
Sanchez) pronounced:

>1. I read that contributors should use the e-mail address
>pylons-proj...@googlegroups.com to report security
>issues found in any Pylons product.
>
>a. Is there any dedicated channel for releasing security advisories/announcements?

There is no channel dedicated to only security issues. I assume
the announcements would be made via this list, pylons-devel, and
Twitter @pylonsproject as necessary.

>b. Do you report CVE’s found in the Pylons products via NVD?

We have not had one yet, but I assume that we would.

>2. As far as I see, you maintain two stable versions: the most
>recent major release and the previous release. Currently,
>Pyramid 1.10.x and 1.9.x. If I understand it correctly, as soon
>as a new major version is released, the oldest of the two
>previous stable versions is no longer maintained? E.g., when
>Pyramid 2.0 is released (I guess it is going to be this year),
>1.9.x will no longer be maintained. Is that so? (An approximate
>period of two years)

Correct, although the exact release date of Pyramid 2.0 is to be
determined. However we could do a better job of publishing this
information for Pyramid. Where would you suggest as a good
place to publish our policy?

It's implied here:
https://trypyramid.com/documentation.html

I think we should explicitly state the policy in our README.rst.

>3. Do you backport security fixes to stale versions (e.g.
>1.8.x, 1.7.x, …), or should users try to migrate to the
>newest releases as soon as possible?

We do not backport fixes to stale versions. Upgrading is the
recommended path.

>I apologise again if I should have posted my message somewhere
>else and would really appreciate if you could point out the
>right place to do it instead.

Not at all. You've brought up some issues for us to discuss and
improve for those who follow in your footsteps.

--steve

------------------------
Steve Piercy, Eugene, OR

[Bert JW Regeer]

> On May 10, 2019, at 06:27, Steve Piercy <steve.pi...@gmail.com> wrote:
>
> Thank you for asking the questions. You've asked a couple of questions for which we have not yet established and published clear procedures, so we'll need to update our policies.
>
> https://pylonsproject.org/community-support.html
>
> I think we've just assumed what are best practices without defining our procedures, but I'll defer to our more experienced security issue response team members.
>
>
> On 5/10/19 at 3:08 AM, asan...@phoenixcontact.com (Aritz Sanchez) pronounced:
>
>> 1. I read that contributors should use the e-mail address pylons-proj...@googlegroups.com to report security issues found in any Pylons product.
>>
>> a. Is there any dedicated channel for releasing security advisories/announcements?
>
> There is no channel dedicated to only security issues. I assume the announcements would be made via this list, pylons-devel, and Twitter @pylonsproject as necessary.

Just reiterating this, we do send out notifications of new releases on a variety of platforms, mailing list, twitter, and I post on Keybase. This will include call-outs on security issues:

https://twitter.com/PylonsProject/status/1091407873496702977

>
>> b. Do you report CVE’s found in the Pylons products via NVD?
>
> We have not had one yet, but I assume that we would.

This is inaccurate.

The project Colander which is part of the Pylons Project was recently fixed for an infinite loop in the regex for validation that could have led to denial of service attacks, I received and got

CVE-ID: CVE-2017-18361

assigned as the CVE ID, this information is also available in NVD.

https://nvd.nist.gov/vuln/detail/CVE-2017-18361

Yes, we do report CVE's and Mitre submits those to NVD.

>
>> 2. As far as I see, you maintain two stable versions: the most recent major release and the previous release. Currently, Pyramid 1.10.x and 1.9.x. If I understand it correctly, as soon as a new major version is released, the oldest of the two previous stable versions is no longer maintained? E.g., when Pyramid 2.0 is released (I guess it is going to be this year), 1.9.x will no longer be maintained. Is that so? (An approximate period of two years)
>
> Correct, although the exact release date of Pyramid 2.0 is to be determined. However we could do a better job of publishing this information for Pyramid. Where would you suggest as a good place to publish our policy?
>
> It's implied here:
> https://trypyramid.com/documentation.html
>
> I think we should explicitly state the policy in our README.rst.
>
>> 3. Do you backport security fixes to stale versions (e.g. 1.8.x, 1.7.x, …), or should users try to migrate to the newest releases as soon as possible?
>
> We do not backport fixes to stale versions. Upgrading is the recommended path.

We do attempt to make upgrading as painless as possible. We do not have a LTS release and do not have the man power to do so.

>
>> I apologise again if I should have posted my message somewhere else and would really appreciate if you could point out the right place to do it instead.
>
> Not at all. You've brought up some issues for us to discuss and improve for those who follow in your footsteps.
>
> --steve
>
> ------------------------
> Steve Piercy, Eugene, OR
>

> --
> You received this message because you are subscribed to the Google Groups "pylons-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to pylons-discus...@googlegroups.com.
> To post to this group, send email to pylons-...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/pylons-discuss/r480Ps-10126i-4886B700A1B24FBB9B3D70041BDB56DB%40Steves-iMac.local.
> For more options, visit https://groups.google.com/d/optout.

[Aritz Sanchez]

Hello Steve, Bert,

Thanks your for answers. I think, everything is pretty clear. About Steve's question on where to publish the release policy, I would say either trypyramid.com or the main documentation site could be appropriate places to publish the release policy.

Best regards,

Aritz Sanchez

Am Freitag, 10. Mai 2019 18:41:25 UTC+2 schrieb Bert JW Regeer:

> To unsubscribe from this group and stop receiving emails from it, send an email to pylons-...@googlegroups.com.

[Steve Piercy]

On 5/13/19 at 12:57 AM, asan...@phoenixcontact.com (Aritz
Sanchez) pronounced:

>About Steve's question on where to publish the release policy,
>I would say either trypyramid.com or the main documentation
>site could be appropriate places to publish the release policy.

Done!

https://pylonsproject.org/community-support.html
https://trypyramid.com/documentation.html

Thank you for bringing up the questions.

[Jonathan Vanasco]

On Monday, May 13, 2019 at 4:17:05 AM UTC-4, Steve Piercy wrote:

Done!

https://pylonsproject.org/community-support.html
https://trypyramid.com/documentation.html

Thank you for bringing up the questions.

I think it would make sense to put a formal policy in place requesting security issues be first reported via the @security email address, they will be in contact within 72hours or so to discuss if any next steps are appropriate, and to please refrain from public disclosure or creating report with CVE within this timeframe. 

SqlAlchemy got hit with a few CVE's recently over some documented behaviors; because the reporters filed a CVE first, it set off a cascade of alerts across multiple projects that use it and packaging systems. The process was a lot more stressful for the maintainer than it should have been.

[Bert JW Regeer]

There's no central authority for CVE's and whether they should or shouldn't get a CVE ID. If you ask for one, you get one. No-one verifies the reports first. Requesting CVE's up front can be annoying, but it is something that everyone has to deal with.

Even if zzzeek had asked for a notice period, I doubt the person would have given it to him anyway.

Would I prefer people contact us on security@? Yes, do I expect it? No, public bug reports are also fine (and that is how that colander one was reported, it was just ignored until I ran into it personally and found it again).

Bert

[Steve Piercy]

On 5/13/19 at 11:33 AM, jona...@findmeon.com (Jonathan Vanasco) pronounced:

>
> On Monday, May 13, 2019 at 4:17:05 AM UTC-4, Steve Piercy wrote:
> >

> > https://pylonsproject.org/community-support.html

> >
> I think it would make sense to put a formal policy in place requesting
> security issues be first reported via the @security email address, they
> will be in contact within 72hours or so to discuss if any next steps are
> appropriate, and to please refrain from public disclosure or creating
> report with CVE within this timeframe.

Thanks for bringing this to our attention.

We volunteers cannot guarantee a timeframe to respond.

I updated the page with an ask not to disclose publicly.