Re: CTRL-BREAK still make sense on Windows for `runserver`?
Ok, thanks for the link Matthew. Just thought I'd bring it up in case things had changed. Seems status quo is fine for now but if Windows keyboards continue to remove the Pause/Break key might make sense to add `Control-C` as Adam notes or eventually switch over. On Tuesday, June 22, 2021 at 6:02:39 AM UTC-4 f.apo...@gmail.com wrote: > As long as runserver (usually) properly shuts down when CTRL-C is hit, > then it imo makes sense to change the text -- especially if that is the > only thing accessible on some keyboards. > > The usually above is because someone might have a bare except that is hit > that moment and as such the process might not shut down. > > On Tuesday, June 22, 2021 at 7:58:47 AM UTC+2 carlton...@gmail.com wrote: > >> I too realise I don't have a(n obvious) break key but have been happily >> hitting CTRL-C. >> >> On Monday, 21 June 2021 at 23:53:15 UTC+2 Adam Johnson wrote: >> >>> Would it be bad to have Django respond to both shortcuts? >>> >> >> I think as a matter of fact it does. At least using PowerShell/Win10/Etc >> — Looking at Matthew's link, we don't do either of the things that would >> inhibit this. 樂 >> >> Looking at it from Will's POV (writing introductory guides) the output >> text of runserver might be a bit problematic: >> >> "Quit the sever with CTRL-BREAK" — Errrmmm... Where's that then? >> >> >> -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/751d9d0f-a387-498f-89be-8a9c7484eea4n%40googlegroups.com.
Re: Google Patch Rewards program
This is great! To the extent we have this teed up internally, makes it much easier for DSF to go to Google and coordinate. And even if Google doesn't pan out, having structure makes it easier for us to, for example, find funding if some fundraising projects in the works pan out. On Tuesday, December 31, 2019 at 11:40:15 AM UTC-5, Dan Davis wrote: > > Another good security improvement would be to allow the database password > and other database information to support AWS Secrets Manager, Goolge > Secrets Management, and HashiCorp vault (+ others). > I have done this in a private package used at the National Library of > Medicine, but my package is both private and limited to RDS PostgreSQL and > AWS Secrets Manager. > > On Tue, Dec 31, 2019 at 11:25 AM Dan Davis > wrote: > >> Taymon Beal writes: >> > First-class integration with one or more secrets management systems, >> both to generally contain secrets better and more specifically >> > so people aren't so tempted to check SECRET_KEYs and database passwords >> into source control. (I think this was mentioned in the list of GSoC >> project ideas.) >> >> What secrets management systems are you thinking about? I wrote >> confsecrets, whose Django integration never worked right, assuming that I'd >> port it to support the following: >> * HashiCorp vault >> * AWS Secrets Manager >> * Google Secrets Management >> >> I also need to switch it from cryptdome to cryptography or make it >> agnostic on these. >> >> P.S. - I have some very limited applied cryptography knowledge - couple >> chapters of Bruce Schneier and some hands-on learning, such as securing >> single license features with signatures based on my employer's license >> signing private key, and discovering that a customer literally pulled one >> set of feature.xml/feature.sig files from one tarball, and another from >> another tarball to game my home-grown licensing system. I helped that >> company eventually move to a Secure USB dongle, and that was my last moment >> of systems software development :) >> >> On Sat, Dec 28, 2019 at 11:23 PM Taymon A. Beal > > wrote: >> >>> (Disclosure: I'm on Google's security team, and my views on this topic >>> are informed by what kinds of things we tend to look for in Web frameworks, >>> but here I don't speak for them, only for myself.) >>> >>> Beyond those already mentioned, here are some potential security >>> improvements I'd like to see in Django: >>> >>>- Support for contextual autoescaping in the template system. The >>>current autoescaping behavior is better than nothing, but it still makes >>>XSS far too easy, since different kinds of strings are XSS sinks in >>>different contexts. >>> >>> https://github.com/google/closure-templates/blob/master/documentation/concepts/auto-escaping.md >>> shows >>>an example of how to do this sort of thing more securely. >>>- First-class integration with one or more secrets management >>>systems, both to generally contain secrets better and more specifically >>> so >>>people aren't so tempted to check SECRET_KEYs and database passwords >>> into >>>source control. (I think this was mentioned in the list of GSoC project >>>ideas.) >>>- Capability-based authorization. Right now, you have to explicitly >>>check for all relevant permissions everywhere, and if you forget, or >>> even >>>if you accidentally include the wrong variable in a template, you can >>> leak >>>data or worse. It'd be much safer if the allowed permissions could be >>>defined at a single choke point, and from there, all model access within >>> a >>>request could be mediated by the specified authorization rules. Ideally >>>data that the current user isn't supposed to see would not even be >>> fetched >>>from the database. >>> >>> Taymon >>> >>> On Sat, Dec 21, 2019 at 11:29 PM Asif Saif Uddin >> > wrote: >>> Really good plans Adam! On Saturday, December 21, 2019 at 11:51:11 PM UTC+6, Adam Johnson wrote: > > I just saw Google is expanding their Patch Rewards program for open > source security improvements: > https://security.googleblog.com/2019/12/announcing-updates-to-our-patch-rewards.html > > They are offering two tiers of rewards - $5,000 or $30,000 - for open > source projects making security improvements. I think Django would find > it > hard to fit in the "small" tier - we generally fix known vulnerabilities > quickly - but we could use the "large" tier to fund a bigger GSoC style > project. I suspect it would need active involvement from a DSF member to > push it through. Not sure how the funding would work in terms of DSF and > paying for development time on the project. > > Some projects that could fit: > >- 2FA built-in to django.contrib.auth (as suggested for GSoC as >well in this thread: > >
Re: Make Development More Accessible
I think the way Rails does it, aka with well-done newcomers guide (https://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) is worth looking at, as Carlton notes. A bit more streamlined than the current Django How To Contribute Guides. Incidentally, Carlton and I will be having a chat with DHH of Ruby on Rails fame in September for the DjangoChat podcast so if there are any questions we should pose to him on managing the Rails community, do pass along to us. Certainly I'll ask him about issue tracking! On Thursday, August 8, 2019 at 3:08:39 PM UTC-4, Tim Graham wrote: > > Although I'm not engaged too much with Django development now, a big > drawback of moving to GitHub issues for me would be that I could no longer > do a Google search like "something something site:code.djangoproject.com". > I could pretty much always find the ticket I was looking for that way. > Maybe GitHub issue search would be just as good but I find Google results > (with a snippet from the page) more useful. > > Another migration consideration is that Trac tickets are formatted using a > different syntax than GitHub issues. > > A migration feels like weeks of work and it doesn't strike me as a "heck > yea!" improvement. There would probably be benefits and drawbacks. As > Carlton said, I think it's time that could be more usefully allocated. > > I wonder how putting issues on GitHub would increase engagement? Is it > that Trac isn't discoverable from GitHub? What if GitHub let us redirect > https://github.com/django/django/issues (with the "Issues" tab) to > code.djangoproject.com? > > On Thursday, August 8, 2019 at 4:48:14 AM UTC-4, Carlton Gibson wrote: >> >> Just on this point: >> >> > I agree with Andrew Godwins statement on Django loosing many >> contributors over the years and being in largely maintenance mode. >> >> First, I'm not sure Andrew actually said this. Rather I think he reported >> is a point raised. However... >> >> I hear this kind of thing said. It ties-in with the "Django is boring" >> trope, when that's not meant as a compliment. >> >> I think it couldn't be further from the truth. >> >> Yes, these ain't the wild west days of yore. (Granted) >> >> But Django has successfully transitioned (with large thanks to the effort >> Tim Graham put in as Fellow over that time) from young to mature and it >> still growing. >> >> Even if you take out your favourite headline feature — don't say it :) — >> v3.0 is going to be an awesome release. 2.2 was too. And 2.1. And it's >> continuing forward. >> >> I wish we'd drop negative self-talk. It lowers morale and isn't even >> correct. Django is in great shape, and only getting stronger. >> >> Could we do with more contributors? Yes. So let's do what we can to make >> that better. >> >> I think of the effort to move from Trac. Maybe it's worth it... But I >> think of the same effort spent improving djangoproject.com, and the How >> to contribute guides (I think Tobias said the Contributing docs are >> X-thousands of words—all great but not necessarily that approachable), and >> so on, and I wonder if it's the best ROI? (That's a genuinely open >> question: DRF uses GitHub issues I don't see it leading to any more >> engagement there...) >> >> Go Django Go! >> >> >> >> -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/ace34012-e5ac-4bbc-ad5b-d3fbac1a560a%40googlegroups.com.
