On Wed, Apr 4, 2018 at 9:43 PM, 'Michael Yoder' via jackson-user <jackson-user@googlegroups.com> wrote: > On Wed, Apr 4, 2018 at 6:30 PM, Tatu Saloranta <t...@fasterxml.com> wrote: >> >> This sounds like useful for many users. Thank you for sharing! > > > You're welcome. > >> Some thoughts.... >> >> On 1.x; there is: >> >> https://github.com/FasterXML/jackson-1 > > > Oh, I didn't realize that. I forked from codehaus/jackson; did I miss any > commits?
I think there was some confusion earlier, when Codehaus shut down so that didn't help. There have been couple of patches there, but not a ton. >> >> from which it would be nice to still release 1.9.14. But as things >> are, there is no Maven release process into Nexus >> that works (1.x uses/used Ant, with ant-maven plugin, which may or may >> not work and that required bit of manual wrangling with gpg signing). > > > I fiddled with that for awhile, didn't get anywhere (I'm not all that > experienced with ant-maven), and took a different route. Actually, kinda > hit it with a hammer - a script that does a direct push with curl: > > https://github.com/cloudera/jackson/blob/jackson-databind-1.9.13-cloudera/bin/deploy-mapper-asl.sh > > No one outside cloudera could use it, since it's got cloudera-internal > links, but you get the idea. It's also jackson-mapper-asl only. Ok. Yeah, if that was trivially easy to solve, it would already have I'm sure :) (not just by me but by others, I know this is sort of widely-wished-for thing) > >> >> The main complication for Mavenification was, I think, challenge of >> producing 2 jars (-asl, -lgpl). But at this point I think I'd be fine >> with just -asl variant. >> >> On security-related fixes, I added tag `CVE` in github for >> jackson-databind. That might make it easier to see security work. >> >> There's blog article on vulnerability (all of CVEs, aside from earlier >> XML ones, are for just one specific attack, just using different >> gadget classes): >> >> >> https://medium.com/@cowtowncoder/on-jackson-cves-dont-panic-here-is-what-you-need-to-know-54cd0d6e8062 > > > I did see this, it was *quite* helpful. Ok good. I wrote it as I didn't see in-depth explanations. And since it's not trivially easy to understand due to many reasons. Not the least because Default Typing is kind of esoteric feature. >> I have also suggested that perhaps there should be jackson-security >> mailing list, which would not be archived, and would require approval >> for joining -- this would make it possible to discuss security issues >> before fix. If anyone has suggestions on good way to go about this >> (that is, I can se up mailing list / group, but I have not managed >> security-related ones and assume there are things I should know), I >> would love to hear. > > > It works pretty much like you'd imagine - a closed mail list, trusted > committers on it, etc. Typically named "security@<project>.apache.org", in > your case I'd imagine something like "jackson-secur...@googlegroups.com" Yea, that would seem like the simplest approach. > >> As to existing discussions: I only add details after merging fixes, >> but this does occur before releases. I am not sure what would be good >> way to go about this -- I assume separate bug tracker, with visibility >> restrictions would be the way to go. Similar to closed mailing list? > > > The Apache algorithm for CVEs is, essentially, > > Someone reports something bad (via email to the security list) > Acquire a CVE number > Fix the issue, but in a non-obvious manner. Sometimes this means mixing it > in with another fix, a non-descriptive commit message, etc > Release > Announce to the world that there's a CVE, the vulnerability, and that they > better upgrade. > > I've never heard of using a separate bug tracker. Typically all the > vulnerability discussion happens on the security mailing list. It's > low-volume enough that you can get away without a separate jira instance or > anything. I like issue trackers, to a degree, but big part may be just for my own benefit. Part of the problem is also that although it is possible to file an CVE, that has its trade-offs; on one hand, there is the whole ecosystem for downstream that gets notified (plus side). Downside that there seems to be little control over how things get handled (at least to me it seems like a black box), so it's maybe more a placeholder than useful for storing anything about state. Then again, if and when CVE entries are public, visibility isn't much lower than for github issue entries. -+ Tatu +- > > -Mike > > -- > You received this message because you are subscribed to the Google Groups > "jackson-user" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to jackson-user+unsubscr...@googlegroups.com. > To post to this group, send email to jackson-user@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "jackson-user" group. To unsubscribe from this group and stop receiving emails from it, send an email to jackson-user+unsubscr...@googlegroups.com. To post to this group, send email to jackson-user@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
