Security Policy questions

[theodoreb]

Hi,

The Drupal project is considering adding peast as a dependency to provide PHP-based shortening of JS files, by using the compact formatter to remove comments mainly. https://www.drupal.org/project/drupal/issues/3302755

Before that can be approved by the maintainers we have to perform a standard stability review.
If you could answer these questions it would be very helpful for our due diligence!

Do you have any official policies with regards to:

• Release windows/cadence
  • For example, do they happen as necessary on any given day, or on a set schedule after a certain passage of time (e.g. once a month)? From what we've seen there is no set release schedule, and there is a Patch releases every 2-4 months, minor releases every 1-2 years. Is that accurate?
• Backwards compatibility guarantees
  • Meaning, is there any guarantee that a given version will be supported for some period of time, like an LTS? (for the PHP API part)
  • I'm assuming the different JS versions are only going to be added, so that support for parsing ES2016 will not be dropped from the library.
• Security releases
  • For example, does more than one version receive security fixes, or only the current version?

I couldn't find the security policy on github so a couple additional questions:

1. If a vulnerability was found, do you have a process for privately reporting and fixing those issues?
2. Would you be willing to work with the Drupal Security Team to coordinate the timing of a new release if necessary?

I would really appreciate any info you can provide, and please let me know if anything is unclear.

Thanks!

[mck89]

Hi @theodoreb, i'm glad you guys are interested in my project, i have no official policy and i'll try to answer all your questions but i need to clarify that i work on this project on my spare time and just as a hobby now.

Release windows/cadence
I have never planned a release, i work whenever i have time to spend on it but i can't guarantee when the next release will be. For example, Ecma has started to implement next year's specification and has already merged the Hashbang comments proposal some weeks ago, but i'm not planning to work on it for at least one or two months because i'm very busy.

Backwards compatibility guarantees
Since the project is pretty stable right now i don't think i'll there will ever be the case where i have to change PHP api. I'm not going to remove old JS versions, just adding new ones and the test suite is strong enough to guarantee all versions work.

Security releases
I've always fixed only the current version and i don't think this can change because of the limited time i can spend on the project.

If a vulnerability was found, do you have a process for privately reporting and fixing those issues?
I've included my email address in all files so you can reach me there in case. Anyway, as said before, i can't guarantee an immediate fix even in these cases.

Would you be willing to work with the Drupal Security Team to coordinate the timing of a new release if necessary?
I would like but i can't for the same reasons above.

Some other notes:

• Ecma releases a new version every year so this requires a continuative effort to implement all the new features. Right now i don't want to stop to work on it but i can't guarantee that i will work on it forever.
• I would be happy to accept new maintainers of the project, so if someone is interested to work on it and can invest more time on this than me, feel free contact me
• I read that you want to use Peast for JS minification, that's not what this project was created for, that's just a "side effect" of code rendering so it just strips spaces and omits some braces where they aren't needed. Real minification libraries implement a lot of advanced features to minify code that this project won't do, but i think you already know that.

[theodoreb]

Thanks a lot for your time and answer.

If that can reassure you, we don't need the latest ecma features right away since they're not going to be supported by our supported browsers before a couple of years at least. So that's totally fine if it takes time to make it in. And we have enough people with PHP knowledge in the community that they can contribute support for new features if they need it faster than you are able to work on it. I'm not expecting that Drupal using this library will create more pressure to get things done "quickly", maybe more time spent on code review though :)

We're aware the minification is a side-effect and that is good enough for us. We're tried a couple of other well known php-based js minifiers and they all have edge cases where they silently corrupt the compressed JS, to us a proper parser is the safest way to reduce the size of our js files without introducing more problems.

If you have things that you want to see implemented it could be good to have a few open issues so that people can pick them up if they wish to. I know it's extra work so if you're not up for it that's completely ok too.

In any case, that's all the informations we needed at this point.

[mck89]

@theodoreb the major problem of this project is performance, i've optimized several parts during the years but it's still slow on medium/large files and right now i couldn't find other optimization to apply, so if you find something that can be improved, please let me know or create a PR.

I also point out that i've solved some issues about invalid syntax generated by the Compact formatter in the past, so if you find other cases please open an issue and i will take a look.

I close this issue for now but feel free to comment again if you have other questsions.