Transcript: Django Security - Markus Holtermann

I'm Carlton Gibson, joined as ever by Will Vincent.

Hello, Will.

Hi, Carlton.

And to with us this week, we've got Marcus Haldeman, who's um a member of the Django Technical Board and on the Django security team, and you know, is on the Django ops team.

He's just a a stalwart of the community.

Hello, Marcus.

Hi Will.

Hi, everybody.

So I guess look, let's kick off.

How did you get into program?

How did you find Django?

You know, how long have you been with the community?

These kind of, you know.

I'm not even sure.

It's been it's been quite a while.

Um and then got into Django um 2010-ish.

Um as part of the German Ubuntu users.e community.

That's a Django project that's started even before the days of Django 1.0 or something.

It's like 9 0.90 or something.

Like the very, very early stages of Django is when that project was started.

And it's a support forum for the German-speaking uh Ubuntu community.

And yeah, features a bulletin board and news articles and planet and all these kinds of things.

Is that still going?

It's still maintained by a few folks on all it's not unfortunately not open source.

It's uh kind of a thing that we since ever ta uh talk about.

Yes, we want to make this open source.

But because it has so much legacy, it's also one of the things where there's a lot of cra uh technical depth in there that we wanna or that that the folks who work on it these days wanna get out of it before they actually open source it.

Is that the word that was coming to mind?

Yeah, probably.

Yeah.

Any old like so that's that's what um 10 years old, 15 years old, coming, you know, that's an old code base.

And it's it's one of the pro uh it's a project where then as a side effect, like worked so like Flask, Ginger2, all those uh projects came out of um yeah, it's uh it's kind of in the well not early stages of the Python web part, but I guess the Django-ish style uh web development part.

And that got you into Django.

Or was back in the day was on that team as well, and then he eventually kind of like always pushed me a bit to maybe contribute to Django because at that point he was a core contributor as well.

And yeah, that eventually got me into uh contributing to Django after Andrew Godwin merged his migration badge in 2004.

14, I believe.

13, 14, 14?

And yeah, then uh I contributed bug fixes there every other day or something.

Marcus is one of my core, you know, peop go-to people on the migrations framework.

I unfortunately hadn't didn't have the time for the last few years to actually do a lot of things on the migration framework.

Um But I think I it seems there's a bunch of other contributors these days that actually have picked up behind me and behind Andrew and others that contributed on a regular basis and like squash out all these bucks these days.

So so you please go on, Will.

So there's and again, and this is also in flux.

You're on the ops team, you're I guess you're not technically a releaser, you're on the security team, you're on the technical board, though not the advisory board.

So I guess you're and then you're on the technical team, so you're missing two, but all the other boards.

And then that all is in kind of flux because now there's the new technical.

So perhaps um what is the future gonna look like in terms of the organization, right?

Because like the term Django core even is tossed around.

What do you make of all this for a casual listener?

So how should they understand?

who can eventually if if there's a discussion that doesn't come to a solution or where where people can't agree on one of the uh two one of two things, um who can make the eventual or final decision to go like okay, let's go with this way, or or another one.

And um yeah, I g I guess that's that's one of the things that's that's been one of the things that's been around and where we've been trying to do that for quite a while, but never really got around that.

Now James Bennett finally managed to actually write down this debt and the well at that point the Django core team um voted on that and it was accepted with quite a large number of um of votes.

And yeah, so then the future of the Django project is gonna look different.

Look I guess.

Um we're trying to open up the decision-making processes and make those more visible.

So going forward, I think the idea is that there'll be the technical board and then the the one I'm on, which is sort of the non-technical things as kind of the arbiters of disputes or decisions that arise.

Because the next step is an election.

The um they have that um Frank Wiles, who's the president, is gonna be configuring, uh setting up the election of technical board members.

Um frankly, I'm not entirely sure about the exact process of big of from the uh from the top of my head because it's a fairly lengthy document.

But yeah, we need to Yeah,

Basically, the reason why uh Frank is gonna take that on is because we don't want someone on the technical board to be in charge of the forum for voting, but it's just gonna be a Google form with the proper permissions.

Seems like a that will be probably a good idea.

Happening.

Because that's sort of a big thing about so w what are some examples of why that matters for the Django community?

And seems to be just in the nature of how to do those things.

And that that making those decisions in public seems to be the right choice.

I mean, because for example, you're incredibly active and there are members who have the title who are not as active.

So I believe one of the intents is to I think they're gonna that's gonna be a a legacy thing that can be bestowed, but but to have the technical team reflect the current active members as opposed to people who were maybe more active in the past.

Um but then these even yeah, if as you said, if you then don't actively participate in the whole development of that, then you still seem to be on this list of people who are in there and you can still take credit for for that position.

And sure, then you have contributed in the past a significant amount of work, and that was usually the thing that's kind of led somebody to become a core core member, then um it's using that position or using that title that you had in the past kind of made sense and um seems fine to me.

Um but over the last years it's been clear that this is not really like this big thing in Django that somebody could do to become a core committer or core member.

Um and the things that you in in the past indicated somebody becoming commit access are just not really there anymore.

So finding a way to become c a core committer wasn't just something that still existed.

So dropping this whole concept and acknowledging people who had be had this position in the past, but then essentially dropping this whole position um seemed kind of like a better or good way forward.

Yes, so so that's part of the Exactly.

And some people, a small number, I think like three of three people, um had release access, which meant they had the possibility to put packages in PyPI.

Um and with the with this with the new change of the DEP 10, this also changed in a way that you don't need to be or you yeah, the we we will have a merger role, which is the people who have commit access to the Django repository, and we have a releaser role, which are the people who have access to Pype I and can put packages on PyPI.

Um people can be in both, but they don't have to be.

Um so if you for example don't have the time to constantly review and or time to merge patches, um and and specifically review is not necessarily up to the mergers.

They should yeah, they should be doing like a send it uh like a check on style and and so on, and do a like general review under PR that it makes that whatever is committed or that whatever they commit makes sense.

But um the discussion if the approach is taken in a PR should be taken by the community and by people who are going to be involved in this in this change.

It's it's kind of the you know, I always describe the fellow role as like the janitors, by the way we speak before.

Um that's kind of what we do is we just you know just keep it tidy.

I mean we do do reviewing and all that.

Um you do far more than just being the janitor in the for the Django project, but yeah, it seems to be a significant role to to what you're doing.

And so when people do leave, there's a process, as you said, for new people to come in to be a handoff of of knowledge and power.

I mean, even for example, so we added GitHub sponsors to uh to the Django repo, and that's something I worked a lot on.

So I have access to part of the Django repo, but I couldn't fill out the form, so I had to get Marius, who's the fellow, because he has you know more access.

So these layers of permission are important just in case you know you don't want it someone to have the keys to everything and you want to have a bit of structure, but not so much that it's prohibitive to get anything done.

Yeah, this is how I think about this as any.

You you can't you can't have a a package being uploaded as Django to PyPI if it isn't Django.

Yes there's too many people depend on it being Django for for that to happen.

There's opening up the whole thing, um opening up the whole contribution process to Django and um allowing more or less arbitrary people to be to be voted on to be um mergers or releasers comes with a side note that we with a perspective and me taking this from a with a perspective of a more security console conscious person right now comes with

a the problem that we need to trust that person to not put in some like backdoor or whatever in that release package that somebody needs to inspect and and find.

And so yeah, it's the the the selection process or the vote voting process on who becomes them will be open according to the things that are stated in the depth.

Um but it's definitely gonna also gonna be something where the community needs to look out for that not some random malicious person is going to like hijack Django because that's not gonna be a good uh

But um the the the the qualification to be on so the technical board have to um uh okay the nomination of mergers and releasers for these important roles.

But to be a candidate for the technical board, so the technical board will be elected by the DSF members.

So already to be in the DSF, you have to be known by the community, right?

Anyone can join, but you have to be known by the community.

Well you can

I wrote a blog post just recently about what the board actually does.

There's I think 180 or so individual members.

So sorry, continue Carlton, but that's like the first step of Yeah.

You have to have a shown uh like a a recent, like within the last couple of years, a shown um history of contributing and reviewing PRs or working on track or the or the you know GitHub or being being in the group.

So to be a candidate for the technical board is actually quite tough.

It's it's not like any any person who isn't known to the community and known to be a contributor could could even stand for the technical board.

I think so.

I think that the term the wording in the depth is is actually very um conscious of the deck of the possible dangers if it were more open.

So I'm quite relaxed about it in that sense.

I mean James did a major part of that, but as again the discussion on the depth was uh held in public on the on the depth itself, on the PR.

It was it took a long time.

I don't even know.

But that's cool.

So let's pick security team.

So you and Carlton are both in a security team, and I think what's the process for a normal security release?

And then there was that the uh GitHub SQL injection injection one recently, which I believe you did the commit for that you you all turned around in two days, a month or two ago.

So the

So what's the normal process?

And then I thought that that that one was particularly impressive, where maybe it was three days, but the it was discovered, the commit was done and it was released.

Yeah.

And so the

Um the usual process for security thing is usually that well, somebody reports either on Hacker One on a security mailing list or security reporting list, um, security at Django Project.com.

Um reports a security issue or a suspected security issue.

Like rather be conscious and like think this might be an issue reported, and then we go, like, actually that's not, but that's we we much rather have that than somebody just putting something open in into the open and like oh shit, this is something that we should have like fix now.

Um, so you usually report something in a private way, and then people on the security team are going to review that.

Um, is it an issue?

Is it's like do we need to fix it like now now, or do we have time till to rethink the whole approach we have there?

Um we then usually talk to the reporter and and try to figure out who's going to write the patch who's going to review the patch like we try we we love for reporters to also contribute a patch and then uh the people on the security team reviewing it but if they feel like yeah now it's I don't really feel like writing the patch then somebody on the team is going to write the patch and we then hand out the patch the or the proposed patch to the reporter and ask them to app

ly that and see that this actually fixes their bug in their well probably production environment that they have there.

This maybe goes a bit back and forth once we are done with that we um pre-notify a set of organizations companies um of an upcoming security list uh security release um we also pre-notify the on the Django announce meeting list that there will be a security release on a with a given date and time and then at that point well usually Carlton on it or or or Marius are going to well

commit the patches to the Django repository and issue the corresponding releases and announce at the release.

ose patches are public and so that it's kind of like you have to get all the pieces lined up and it's a little bit tense you know it's it's much harder than a normal release which you couldn't you know you take your time on.

Yeah carry on Mark as you were you were saying so we've

Because you can't like a usual release you can go like oh yeah we broke whatever in there we're just gonna it just don't install the new version like pin something to before and then like take the time to to fix this bug and s or revert it and and issue another one.

But if that happens with a security release you go like oh damn well we just published a security issue which we don't have a working patch version for.

And you go like this is not ideal.

So the the other issue that you you brought up with the um with this with a GitHub uh SQL engine uh it wasn't I think it was like this

It was an account potential account hijack.

Yes yeah it was like the password reset yeah that's what it's um

Yes you guys actually worked on it.

I'm just sitting here like talking over you

did the work.

So you know it could be google.com but the the the O's are funny Unicode characters and then it would look like it was a Google email but in fact it wasn't a Google email.

kind of wasted time because we should instead have that time people already fixing pe fixing their their installations.

Like yes data

Ops team so you and I have had some I I've been emailing around that maybe we don't need to discuss some of that but what does the ops team do?

Like what is the ops infrastructure of Django itself?

So you're on there along with uh Florian Tobias and um Carlton.

of maintain that the the software or the not the not necessarily the software there but the the infrastructure like we up keep Jenkins Jenkins up to date usually we uh when that when there's fixes to the Django website we deploy them um these kinds of things.

want to call that out.

Thank you.

usually or or maybe some l add a label to that and then a timestamp and um well you want to like aggregate data from usually or in in the fo the market we are focusing on is the industrial IoT.

So you have factories that companies have where they equip their production lines with sensors or the machines in themselves are already equipped for sensors and you want to do analytics on on those machines and you want to understand when something goes wrong.

And like this whole in order to do analytics you need to store the data somewhere that you and then aggregate things.

And turns out when you have a lot of plans or or manufacturing lines and and machines and a lot of data and a lot of numbers then you need to s have a database that can cope with that.

And yeah with CrateDB um we have a database that's uh based on Lucene um scales fairly well uh like pretty pretty much almost linearly for I don't know even know how many nodes um and can cope with ridiculous numbers of of records in in tables.

And yeah it's a SQL database after all so you still write your SQL statements and it returns your n the the records.

Obviously there's a lot more that Postgres can't do which is why you work there and you have this product but what is where does if I start a Django project that's IoT and I'm using Postgres, where do I see that oh I need something better or bigger like create?

Like do you have a sense of where that friction comes up?

I suppose you can't.

I guess you can't.

Um, you probably also don't want to, that's it.

Um CreateDB on the other hand is um eventual consistent and you have kind of multi-master or you don't really have a masternode in the in your cluster, you have a an a single node that holds at a particular m set of time or at the current time holds an information about the whole cluster, but that's known is also known to everybody every other node.

But you can write to every other node in your cluster, connect to every one every node, write to every node, read from every node, and it's more or less self-balancing with the data if you don't screw up your table creation.

And you're the what is the advantage of that is that ingest speed, you can pull in the the rate at which you can ingest data is just order of magnitude higher.

I don't even rem know the exact numbers that we are currently looking at with some of our benchmarkings.

But it's sure you can scale your Postgres ridiculously uh high and and improve a whole bunch of inserts.

But at some point it's going to you're going to run into issues.

And then for the most part in create you just add two more nodes to your cluster.

The just in quotes, because it's like just in IT it's never going to be a you can simply again in quotes.

Um but it's

I always try to put simply, just simply install Jenkins.

Exactly.

It goes over well.

So sort of how long does that take?

Because I've used eventually eventually consistent data stores, and quite often that just means where's my data?

You do a write, and then you do a get to get it back, and it's like not found.

And you're like, hang on, I just inserted it and you said it worked.

Where is it?

Um So the I mean how long does that take to run through, say, if you're you know I mean I guess it depends on the size of your class or anything, but

But like you're not gonna wait five minutes for this number to show up somewhere.

I mean if you're if your complete if your entire network is completely overloaded, for sure it's gonna take time, but then you may want to reconsider your network infrastructure.

Yeah.

No, so uh

And you so the uh you said it was based on Lucene, which means it well, the thing that comes to mind is well, Elasticsearch.

How does it compare to Elasticsearch?

Because I know a lot of people use that for high-engest um um use cases.

whole thing and that made up Create TV at that point and then eventually um I think last year, I guess, I think we dropped the in or the core team there dropped the enti dropped Elastic in that sense that's um it's not in the code base anymore.

Um so it's it's I'm not involved in the direct development of the database itself.

Um so I can't actually tell you m that much about the details of the development there and the the specifics around the code.

Maybe you don't, I don't know.

It's just interesting.

Fair enough.

It was just uh, you know

So that's back in 2014, along with Alex.

Uh no.

No?

Oh, whoops.

I got the wrong I was looking up.

Ah, I pulled up wait, oh weird.

I'm sorry.

I was just quickly pulling up um wait, it's on your

Because I I saw you had a talk on Elasticsearch and I was just trying to pull it up and it pulls up from 2014 you have a whole post on it.

And went from C, C, Java, uh, eventually Python, um, to and then in in in the masters and that one calls in the this one uh one blog post you, I guess you're referring to with the school data in Berlin.

Um we figured, hey, how about we just build a static website and then throw all the data we have into Elastic and just query that straight from the front end.

Um but that's about it, what I did with Elastic there.

Um thing I think you carton referred to was a talk I gave

No, what was it?

I mean I've got it here.

It's combining Django and Elasticsearch.

You have the slides.

And I remember it being so good because I at the time I was flirting with this idea that oh, we'll just drop the ORM loader.

If we're gonna sync everything to Elasticsearch and search from Elasticsearch, and even we're gonna serve the web pages perhaps from Elasticsearch, why not just write to Elasticsearch and not bother with the Django ORM at all?

And you were like, no, no, no, because you lose the transaction handling, you lose the ORM, you lose all these and you're exactly right.

And I was like, yeah, that's that's that's answered that question canonically for me.

You're right.

This 2018.

You must watch that on YouTube.

Yeah.

Link in the show notes.

Like the you know, because I I put uh code open source sometimes, and you know, you got a lot of good stuff in here, right?

You have like an airline example, a bank example.

That's and you just sort of casually mention at the end, like, you know, I would just like make a video of that being like, check this out.

It's a lot of work to make that.

And yeah, structured.

I could recite parts of the talk now, but then I'm not gonna do that.

I'll I suppose you can put the link to the talk somewhere in the description um or in the links.

Um I fear I'm gonna spoil the surprise of this talk.

But um

Like it's not just talking, it's like you gave examples.

It's the reason for that is because of the title and the the whole story of how I try to bring this whole title of the talk into uh why you would want to do structured logging.

Um and with that refers to a movie.

We'll we'll put the link up for everyone so we won't ruin it.

So OK 3.0 had the ASCII handler, which enabled you to embed Django in a ASCII environment.

Um so that's the foundation step.

But 3.1 is the starting where we you can actually write an async def view.

Um and okay, that's gonna be basic, and that's gonna that's gonna be fledgling as what we'll be able to do in future.

But it's like, yes.

So now if I I've got my Django project, I need to make a few API calls out, and they need they could be done in parallel without even running a different server, still with Gunacorn, still in the WISGI environment.

I can write a parallelized view which fetches those rather than having to do those sequentially, and that will be much quicker.

And that's that's just a quick gain without having to do anything else.

So, you know, this is the real start for yeah, we can start to do these extra exciting things.

And okay, we'll there there aren't going to be the async class-based views that yet that we'll probably get in a few cut, you know.

When we all learn how to write these views and we all learn what the patterns are, Django support will evolve.

But this is like the for me, this is like, yeah, actually, this is the real async bit.

This is the bit where we like, yeah, actually most of what you can do.

And then and then right after next versions, we need this three-point uh pro uh the the the async for database level, I guess.

Because that's still not

I mean, yeah, I mean so yeah, this is the limitation is if you're still using the uh the ORM, you that still needs to be wrapped in a sync sync wrapper and executed in a thread.

So a lot of the things you want to do, they work they'll still be sync.

Yeah.

It's like exactly.

Um I mean this I'm excited.

I've been right for years I had to spin out a Node.js on the side before before Django had async, uh before Python had async.

You'd have to spin up a JavaScript thing to do something async.

And then Python's had async for a little while with async IO, and you know, there are other options, but async IO being the standard library option.

And you think, okay, well, I can just do it with async IO fine, brilliant.

And there are a couple of web frameworks around that in um that we've talked about Tom Christie Starlet as as a go-to there.

But to not even have to change a web framework to do the basic thing, that's yeah, it's more and more stabilized all the time.

So not that it's a competition, but I I hope to get I I guess David Lord or someone on from Flask to talk about how they're doing it, but it's it's gonna be another reason that Django just marches into the future and you know, when they people say async, yeah, you can you can do that.

Though of course, like in I mean in Andrew's talks, to me the interesting thing is the use cases for async aren't as ubiquitous as maybe we thought they would or the community thought they would be five years ago.

Yeah.

Um like that to me is sort of the interesting piece.

I mean, you know, in the same way that we have HTTP too, but it's not aside from gaming and chat, maybe well per perhaps in you know in in IoT cases it's being used, but it's not used everywhere.

And frankly most websites and yeah, should chat and and all these things, they are not particularly normal websites in that sense because there's a whole part of this media part in there.

But regular websites, it's well, here's my my my view that fetches a few things from the database and returns a bunch of HTML for the most part, or returns an API a bunch of stuff in a JSON response as an API.

There's not a lot of not really a lot of IO happening when you compare it to a bunch of other scenarios.

And yeah, you may get a bit of speed up here and there.

But the occasionally I think that the mental overhead that you need to apply there in order to wrap your head around async can easily reduce the maintainability of the of that page then.

Yeah.

But um there was a note saying something like we we advise you to keep using sync until you've profiled and you know that there's a real benefit here.

Don't just jump onto the async bandwagon because you think it's cool.

I mean it is cool, but like that's not a reason to build your product in it.

It's it's definitely an interesting approach and and and interesting w way of writing code.

And I mean the whole front end part in web has approached that for a while now and has been doing async for quite a while.

But then in the front end you have direct user interactions where you want to do bubbles here and and show things they are um asynchronously, um, which you don't really have in a web server backend with like APIs for the most part anyway.

So there was uh the Phoenix project which is in um Elixir.

Yeah, they had uh they've got a thing called LiveView, and then somebody's ported that to Django.

There's a Django LiveView project which is really interesting.

I think they're I think they're using channels under the the pack.

But what's nice about it is that um the the front the say a form can do um validation on the server side because it it's doing what looks like local client-side JavaScript validation in the form, but it's actually pinging the server and getting the response there.

And one of the issues with writing decent JavaScript has always been, oh, I've got to rewrite my validation logic, and you know, it's always been a bit of a pain.

I'm not

It's just the interpreter um that you throw some Python bytecode at, and the interpreter is written in JavaScript, so runs in the browser, and then you run this Python bytecode in the browser.

Um so it's part of the BWAR project.

I think he referred to that in his keynote at PyCon last year too.

Where Probably, yes.

Well, maybe uh for me, like a final question.

So this is something I was hoping to do in person at DjangoCon Europe, but since we're in a virtual situation, uh so sitting on the board, a lot of what we do is a janitorial side of Django, paying the bills.

But one of the things I want to do is be a little bit more aggressive around if we had a grant fellowship, if we you know didn't have to rely on Kickstarters for major new features, what would be some features that you think would be good for Django to add, assuming we had unlimited people and money?

You know, are there a couple that come to mind between the two of you?

I get I mean authentication is a big one, right?

auth could user overhaul, let's call it that, make it a bit more modern and adjust it a few um modern security or or authentication processes, like stuff like um auth or two-factor or in in in whichever way authentication.

Um I think the thing that's been on the docket for ever is a new admin.

There's this

I I have the feeling this was Jacob.

I think.

Um yeah, if if if we have a million dollar uh million dollar and a few folks, I think you mentioned ten to ten people or so that's that spent a year, then this is achievable or something like that.

Um yeah.

I think the big

I'd like to see two-factor auth built in.

I'd like an easy solution for users to be able to you know have one-time passwords, have you know, yeah, all the other bits and bobs that come.

Um I

But my one big missing battery at this point is 2FA of some kind of modern you know, um use your uh you use your smartphone with its bio things bio registering security measures and j know that it's you that's logging in.

Yeah.

I think we could we could do that now.

There's I mean it it's a big job, but

And absolutely once once it was clear that Django itself is going to have some async capabilities is an API for task execution.

So not the execution built into Django, but an API where you if going like I wanna put send off this task and do thing, and then whatever implementer implementation project uh or ever project is out there that wants to implement that can use and can build on top of that.

So your what uh just to pick one salary Django integration would um leverage that task that is or this task interface that Django or could anyway could leverage that task interface that Django uses and you define whatever this one setting in your in in in Django in or in salary and it again quote unquote just works.

I remember having a discussion with that in Cardiff at the DjangoCon.

So that that was 2015.

Right.

So I don't want that to be the limiting factor.

I I hope to encourage that you know we again we don't rely on Kickstarters but it's sort of it's sort of the chicken and egg where I mean because the total budget for the Django Software Foundation is around 2000 most of it goes to the fellows then to conference workshop sponsorship and that's and then a teeny tiny amount for the ops and and whatever and that's it because we don't need more and we're not trying to raise a ton of money but if some feature was fifty thousand dollars you know whether it's getting a grant from Google which has provided help or

some of these corporations or you know there's a number of other ways we can um

look we're aiming to improve Contrib we're aiming to you know introduce a a back end system if that's what the technical board come to the conclusion with consulting with the community then we will have that um that list of ideas which are that list of things we want which then you know the DSF board or the membership can act on.

s a possibility to build a API in Django or build the buttons and bits and pieces into Django that um then third party applications can use and leverage that to build a more sophisticated path to be used in as as um as applications.

I guess that's that's definitely something where we definitely will rely on the or need to rely on the community to bring up ideas there.

So we don't really know a company's using Django unless there's something open source or someone from there tells us by design but that does limit sometimes the new features and things that we can add.

m guessing here.

I mean because we can you can see on PyPI you can see the number of Django downloads but the PyPI stats are there's many ways that those are unreliable actually um so I I mean I I think our take to be conscious of secure of privacy and all these things is the right one but it does mean it takes a little more work to find out what how people are using it.

I mean literally I mean Jeff Triplett and I are trying to or Jeff Triplett's been working on a list of like the top 500 companies using Django and it's a bit of work to find that in part so we know who they are that we can ask them around features.

We could you know try to suggest sponsorships and stuff but like we have no idea who they are just um yeah without doing the work so the manual work.

That's not necessarily a problem you opt into all of that and you know about it but

it's not how

just doing.

You know everybody's working quite hard on keeping Django moving and it moves fast.

You know look at the last few releases they've all been you know just major great releases.

Because I know that everyone who's on you know our mailing list knows who one another is but most people don't know.

And I not that people do it for that reason but I think it's important to as you to your talks Carlton right we need new contributors there's a lot of strength but there's quite a bit of fragility when it's a half dozen people doing you know two of you are on this call are doing a lot of the working

boat call it's video call so if a meteor strikes one location this would be okay

the technical team and and trying to enable that um so

15?

15, 16 yeah something like give or take?

Yeah.

it's quite a while it's gonna be a few more yeah more things.

Yes.

Join us next time bye bye