So, I'm Barry Jaspin and I'm talking about easy Drupal hosting life cycle, how to have your site running in a development staging and production environment and various ways of going about doing that. Other people at this conference, there are some similar talks or talks on more details of various aspects. For example, I just attended Marcus DeGlas's talk in the previous session where he went into a lot of detail about WebAstrono and some similar other tools. So there's a lot of different pieces of information. This is going to be one take on it. So before I begin, this is probably a review for most of you, but just to get some terminology clear, I'm going to talk about the anatomy of a Drupal site. So every Drupal site consists of four things. One of them is, of course, the PHP code, which runs the site. Then, of course, there's an SQL database, which is the primary Drupal database for the site.  And then there's the settings file, and my abbreviation for settings is a bit unfortunate, but that's what fit in the image. And, of course, that is what ties the database and the files to the code or tells the code which database and files to use in a single site setup. It's a, the settings files are pretty simple affair. Of course, Drupal also supports multi-site arrangements, where the settings file becomes a little more interesting. In a multi-site arrangement, of course, you have still the code, but then each separate domain needs its own database and its own files directory and its own settings file to tell the code for any particular request, which database and which files to use. So in the previous slide, there were four pieces that you have to manage. In this scenario where you've got two domain names, now there's seven things, seven items you have to manage. And that makes it a little more complicated. If you want to have multiple environments for your site, there's just more pieces to track when you do actually have more environments. So here we've got seven pieces, but in a multi-environment setup, you actually need a lot more than that, right? So if you have a staging and production environment, now you've got 14 different pieces to deal with. And in fact, since the best practice that I'm going to talk about is to have at least four environments, a local development environment, a on-the-server development environment, a staging environment, and a production environment, it doesn't all fit on this slide, but you're talking about 28 separate things to keep track of and synchronize from point A to point B. And it's just a lot of stuff to deal with. So let's walk through, pretend you only have two environments because that's what fits on my slide. And let's just review some of the things that you have to do if you want to work in a multiple environment system. So you start off, and I'm going to actually define some terms that I use on the next slide, but some of you, most of you are probably familiar with version control, you start off, you've got your development, your main branch, maybe it's trunk or master, depending on what you're using. And you create a branch to push into your staging environment for testing. OK, you branch your code, and now you deploy that code on your staging environment. Now, after you've deployed the code, you can start to run it. But first, you need to make sure that your settings file for foo.com and bar.com are porting to the right database and files directory. OK, but now you're ready to go. You probably want to work with a copy of your production database when you do your test with your new code. So you copy your foo.com database across, and of course you copy your bar.com database across. And that's fine. And now you do your test. And let's suppose, Miracle, your test goes really well. You're ready to deploy live. OK, before you can do that, you want to make a backup of your production foo.com database and a backup of your production bar.com database. OK, now you've got to make sure your settings file is correct for productionfoo.com and for bar.com. Finally, you make a symbolic tag in your version control system so that you know the exact code that you deployed this day. OK, great. Now you copy that code over to production environment. Now it's live. Fabulous. OK, how many people in the room have ever pushed code to a live environment and only then discovered there was a mistake? Yeah. Then you got to revert the whole thing. That is a pain in the neck. But that's what you have to do if you want to have lots of environments. So before I begin talking about managing all these different pieces, I'm going to talk about two basic tools. Again, probably most of you are familiar with these. The first one is developing locally. I use that. I refer to this later. All I'm talking about there is having some kind of local development environment on your machine, your Windows or Linux or Mac machine, where you can run PHP and MySQL on Apache so that every developer, whether you have one or many, can all work in a local environment. And they forgot a semicolon, so they add a semicolon.  It's a pain in the neck. Then push the code up to the server for every little change you want to work locally.  I'm not going to go into any detail. They exist for XAMP for Linux and Windows. There's MAP that works on Mac specifically. Acquia's Dev Desktop works on Windows and Mac. They're all fairly similar. As I said, I'm not going to go into any detail. But when I say develop locally, this is what I'm talking about. The other standard thing I'm going to talk about is version control. So prior to using version, some people still manage their code on their servers by just editing locally, maybe FTP-ing up, or maybe they even edit the code on the server. What you'll see in a few minutes is that for a multi-environment setup where you're using a separate development stage and prod environment, you really can't do that. It gets too complicated. You forget which file you copied where. It becomes a disaster.  You should be using it anyway. Lots of people walk around Drupalcon talking about different ways to manage code. There is a very simple model that works. It's pretty much the standard model. It's the main branch, release branch, and tag model that I tend to focus on. So the main branch, if it's SVN, it's called trunk. If it's Git, it's called master. That's where you do your live development. When they have a patch, that's where they put it. All the different developers do their initial integration there. They create a release branch when you want to have something to demo to your client, or it's a release candidate. You're going to push it out. And then when you're finally done with that, that release branch is ready to go out. You make, as I said before, a symbolic tag. You draw a line or a circle around it, and you say, this is the exact version that I deployed on this day. It never changes. You have a reference for all time of the code. The tag is immutable. And then, backing up one line, if you ever need to make a new release hotfix from that line, let's say you cut version 1.1, and you make a tag, 1.1.1, and you release it.  You make that in the release branch, 1.1.1, and now you cut tag 1.1.2. Meanwhile, in your master branch, maybe your developers have progressed and added all kinds of cool new stuff, but it's not ready to release yet. So it's progressed to, who knows what point, that's why you need the release branch. That's the code from which your production tag is derived, and you can make a small change into your release branch, push it out to production. And then, of course, also make that small change in your trunk. I'm not going into a whole lot of detail again. I know most people know this already. I'm just sort of defining some terms for later. The important thing to understand, as I said, this is sort of the simple, standard model. There are definitely other models out there. Some people feel like trunk or master should be what you're running in production all the time. That works fine, but it's not the easiest way. If you want to use one of those other models, probably you already know that. You don't need me to tell you how to do it. Very, very briefly, I'm gonna talk about the Holy War. Git versus SVN. Here's my position. They both work. They're fine. Here's how you do basic things that we're gonna talk about in this session with SVN. Here's how you do exactly those things with Git. Bottom line, both of them work fine. The reason I put this slide in, besides just sort of defining my terms, is there's a lot of discussion about, oh, you should be using Git because you can do a rebase and a feature branch and a bisect and then do the other, and it can get very complicated. And so my advice is, if someone is telling you that you wanna do something really, really cool sounding with Git and automate the whatever, if you don't know what they're talking about, smile, say yes, thank you, and then just walk away. When you need that level of complexity, you'll know it. If you don't already know you need it, you don't keep it simple. The standard model, main branch, release branch, tag works great. Okay, enough of the preliminaries. So I'm gonna talk about three ways to manage a site across multiple environments. There are lots of other ways. In fact, in Marcus's talk, he had a whole slide that just listed the name of various tools that you can use. There's things from the Ruby world and things from the Java world that you can apply. And there's, I'm not gonna talk today about AGR or there's something called DrushDeploy, which is in development. I'm just talking about three. The three that I'm talking about, one, doing it by hand, right on the command line, my SQL dump using SSH, because I think it's important to understand sort of what the underlying operations are that are being automated for you by all of these tools. Once you understand what's going on, then it's nice to not have to do it anymore, but it's useful to have the basic model. I'm gonna talk a little bit about how Drush simplifies the basic command line options, ways in which it makes it better for you. And then I'm gonna talk about DevCloud, which is obviously a product of Acquia. So, managing code. So we've already talked about, you know, you always wanna start your developing locally, right? I write my code right here on my MacBook or whatever machine I'm using and I commit it or I test it, you know, whatever I wanna do, I'm running it with a local copy of my database today. When I'm ready to push it to my development environment and the purpose of the development environment really is the initial integration testing among multiple developers. So if I'm the only guy working on a site, you know, to have my local development environment on my notebook and a development environment on the server, it's a little bit redundant. But if there's three or four or more developers working on it or even two, then I'm doing some local development and my buddy's doing some local development and we may each work great on our machines because I don't have his code and he doesn't have my code. The development environment on the server is the initial point of integration where you find out, oh my goodness, we both defined a function with the same name and the site white screens, right? That kind of fits.  And then you've gotta push that code up to the dev server. And again, the reason that's important is if we don't do that, otherwise, you know, there may be basic integration bugs that don't work. So how do you push the code up to the dev server? Well, one common way. Some people deploy straight from a version control system. There's reasons not to. There's advantages to it as well. You log into your server, so slash dev in this model, that's your dock route. Probably it would be slash var, slash dub dub dub, slash something, but that didn't fit on the slide.  You copy the code up. That works as well. Then you wanna, and now you do your integration testing and it works great. Okay, so now we're ready to make a staging release to do a demo. So we need to push it to the staging environment or for our release candidate, say. So again, you wanna create a new branch. All right, you use your command line tool. You say, you know, Git branch or SVN copy or whatever, however you wanna do that. You push that code up to the version control system and then you've gotta log into your server and CD into the directory, in this case, slash test. That's the doc root for your test virtual host and pull the latest code in. Again, here I'm showing you can do it with your version control system or you could do it with our sync. Okay, assume your test went really well and now you wanna push your code up to production. So you do the same thing again. You make a tag, you can use the Git tag command, you can use the SVN copy command, push that up to your repository, then log into your server CD into the production environment. In this case, pull down the latest code with SVN update or Git checkout or our sync or whatever you wanna do.  So how do you do this if you wanna use the Drush tools? Again, you start, you develop locally. You always start, you develop locally.  Again, you've gotta do that integration testing in your dev environment. Okay, so now we're gonna use the Drush tools. We wanna push to development. How do we do that? Well, before we saw SSH CD into a directory and run Git update, Drush makes this a lot easier. You just type drush rsync at local at dev. I don't know if everyone in the room is familiar with what's going on here, but in Drush parlance, those things that begin with an at sign are called aliases. And there's just a config file that you create once somewhere. So you don't have to type it over and over.  And when I say at dev, I mean on server12.whatever, here's my SSH key, and it's in the directory, you know, vardubdub slash dev, wherever I put that code. But then having done that once, you can figure that, you set it up, it's pretty simple. Then you have, you know, shorthand references. And what this does is it rsyncs your code from the local environment to the dev environment. Now I do wanna, there is a problem here. Remember, the whole reason you have the dev environment is if you've got multiple developers working on a site, you need to do basic integration testing. Well, if I do some development, commit the code, run rsync, and it runs in the dev environment, works great. My buddy, she writes her code, she commits it, she pushes up to the dev environment with rsync, she runs it, it works great. The problem is that if I forget to do a Git pull or an SVN update, I don't have her changes. If she forgets, then she doesn't have my changes. Both of us have pushed our code to the development environment. We haven't really done integration testing yet because neither one of us had each other's code. So that's a downside to using rsync that I referenced earlier, and this is the way that Drush makes it easiest to copy your code around. So you just have to be aware of that. If you're using this, everyone has to remember always do a Git pull or an SVN update before you do the rsync so that you know you're pushing the most current integrated code.  You want to push to staging to make a release candidate. You locally make your branch using whatever tool you want and then you drush rsync, push your code up again. Much simpler than that SSH command we had to type before. Again, here I've assumed I've defined an alias called attest, and drush is smart enough to know even if dev and test are on different servers, it'll make an SSH thing and pipe it through and it handles all that for you. All right, last stage, I want to push it to live. Again, looks very similar. I make my tag and I can use drush again to rsync for my test environment, to my production environment, this pushes my code up. Great, much easier than remembering those long commands. This works well, a lot of people do this. A third option that I want to show you is how it works with DevCloud. So again, you develop locally. You always develop locally.  Looks very similar. On DevCloud, as soon as you commit to the master branch or the trunk branch, the code is automatically deployed in your dev environment, so that's just a step you don't have to do, we do it for you. When you want to move your code from development to staging or production, there's a drag and drop UI you can use. So what this shows is in the UI, you've got three environments, DevStage and Prod, you see that the dev environment is running under the change two box, it shows you two things. One, it shows you what you're currently running and on the next slide it lets you change it, I'll show that. But this shows that dev is running the master branch, so it always has the tip of that branch deployed. And when you drag that to either of the staging environment or the production environment, what it does is it creates a symbolic tag just like we did on the command line in the previous slides for the tip of that branch and then deploys that code in whichever environment you drop it in. So here you can see that production is running something from July 14th and the last time we dropped something on staging was August 12th. This system by default names its tags with the date. We found that works pretty well, but other options are possible. So this makes it very easy to push your code across different environments, though you still have the option of manually cutting your own branches and tags if you want. You don't have to use this UI to do that. What I didn't address with the other systems that I'll show you here is the revert step, oops, oh my God, I've just pushed out a bug. On dev cloud the other thing that changed to drop down as four is it just shows you all of your branches and all of your tags at any time. You just select one, you press confirm and it pushes the code out to that environment. You could do this with the command line, either manual command line ways or the drush. With drush what you would have, with either of those what you would have to do is using your version control system on the command line check out the branch, the version, the tag or whatever that you want to push live and then type the drush command or the arson command or whatever again. So it's just a little bit more manual. Frequently when you're trying to revert code you want to do it as fast as possible. So that's why I showed it that way. So that's code. Questions before I move on? All right, well, since we did talk about pushing out release candidates in that segment, which of course release candidates abbreviated by RC I just thought we'd take a little break and celebrate with a little bit of RC. You know, just to keep things entertaining I decided to bring this with me. Wee! Okay, that's fine, great. Bring this home. Whoops, no, come back, come back. No! Okay, great. So, sorry I couldn't resist. That's what we do in our office all day long when things get stressful. We start flying helicopters and shooting them with Nerf guns, so. Okay, managing files. So remember, Drupal site has four basic things, code files, database and settings files. I'm actually not gonna talk much about the settings file in this talk. We talked about code. Files work pretty much the same way with doing it basic way and on the end with Drush. With files you pretty much always use R-Sync. There's no, you know, they're not versioned. There's no problem with my buddy making a change to a user uploaded file or me. So you have these really sort of awful looking SSH commands. No one, no human would ever really wanna type these. But this is what it looks like, right? So, to copy from local to your development environment you use the first bullet, right? So I'm assuming, you know, .slash, that's I'm running this on my local computer. So I'm here, I'm syncing my files directory up to my dev environment, you know, the next two sync up to the test environment or the production environment. Pretty straightforward, but kind of a pain in the neck to type. Drush definitely makes it a lot better. So here, again, you use the Drush R-Sync command, which is the same one I showed for pushing code up. But what Drush defines in addition to the aliases for at local, at dev, et cetera, it defines, I don't know what its term is, but this percent thing where it's a reference to a path. So here you can say I want, you know, the files directory from my local environment or the files directory from my test environment. And this is a symbolic reference to it, so this lets you copy pretty easily from one environment to another. Much, much simpler to type that. You can obviously also you can script any of these things. One comment on the manual thing on the left is it's actually a lot trickier to make those work if your test environment and your production environment are on different servers, R-Sync actually can't, you can R-Sync from local to remote or remote to local, but you can't R-Sync from one remote to another remote. It just doesn't support that. You've always got to go through the local machine. So if you do try to do that in one step, what you end up with is you SSH to one, and then from the one, you R-Sync to the other, so you end up forwarding your, it gets a little subtle, Drush does that for you from one way or another. I'm pretty sure the R-Sync command is smart enough for that. But that's pretty much, it's fairly straightforward. The R-Sync is a way nicer to type under Drush. The way we do that on DevCloud is just like with the code, it's a drag and drop. Interesting thing is that on the, let me back up a little bit. What this is letting you do is, in this example, I'm copying sites, default files. These aliases that I've defined, I haven't really talked about it, but you can define different aliases for different multisites. In my initial anatomy slides, I was showing you how you can have foo.bar and foo.com and bar.com. Well, you can make an alias for local.foo, and that's specifically the foo.com database and the foo.com's files, so then when you say percent files, Drush is gonna know at foo colon percent, sorry, at local.foo colon percent files, if you set the aliases up right, it will know that that's actually not in sites default files, that's actually in sites slash foo.com slash files. So the Drush approach makes it really easy if you wanna sync your files for one multisite at a time. That makes it pretty straightforward. Doing it the left hand way works as well, but you gotta type the paths in all by hand. The reason I'm making that distinction is, one limitation currently of the DevCloud user interface, we do have the drag and drop for moving among your environments, but it syncs all of your environments, all of your multisites at the same time. So that's why it says all sites colon files. So when I drag from my staging or my pre-dev or wherever to wherever else, it basically is taking the whole, all of the files directories under site simultaneously, which is frequently what you want, but if it's not, that's fine because you just fall back on the Drush way and with DevCloud we define cellular analysis for you so you can just run Drush for individual sites if that works for you. For managing databases, it's not too different than managing files. So the sort of the manual and Drush ways, again, look fairly similar. The manual way, of course, the way all of these systems work for copying individual databases is MySQL and MySQL dump. So on one server, you SSH in, you run, so it's a little interesting. If you look at the second line first, you SSH in the server, you run MySQL dump, give it the database name that's the source and you pipe that through MySQL to the destination name and it loads it in. And that works fine except that when you do this operation, you sort of expect, okay, now my destination is an exact copy of my source. Terrific. But suppose for example, you're doing some development and you've added a new field, a CCK field in D6 or a new entity or field in D7 and you've pushed that to your staging environment and you copied your database with a command like this and then you discovered you made some kind of mistake. Well, that's good. You're still in Dev and testing.  Now you copy your database again and you create the field again. What you discover is that table already exists in the staging environment that you're copying to. Why? Because when you do the second command and you say dump the source database to the destination database and you then create a new database in the destination. When you go copy again, the MySQL dump contains commands to delete all the tables and then recreate all the tables that are in the source. But if there's a table in the destination database that isn't in the source it's not gonna get deleted. You end up with an exact copy of all the data in your source database plus whatever else happened to be there in the destination. So that's why in the first line of this example you have to drop the whole database and recreate it or explicitly drop all the tables before you do a command like this. So this clearly is nothing any human would ever wanna type on the command line. It gets even more fun if your databases are on different servers. I show more detail here than for the files case where you SSH into one, you do the dump, you pipe it through gzip maybe, then you SSH into the other and you unzip it and then you dump it in. So it's not really that different. It's just more typing. Thankfully Drush makes this a lot simpler. One handy dandy little command. SQL sync is kind of like R sync. Behind the scenes all Drush is doing is it's SSH into one and running my SQL dump and then the other but it basically abstracts it all for you. And the Drush command I believe handles the multi-server case as well and it knows to drop the database and recreate the database and so obviously much, much easier than typing that horrible SSH statement. The way we do it on DevCloud not surprisingly is a drag and drop operation so you choose where you wanna copy from, you drag and drop it to whichever environment you want and guess what behind the scenes it SSH is in and runs in my SQL dump and drops the tables and does all the same things. And incidentally again you don't have to use the UI you can use SSH and Drush on DevCloud just like you can without it. Okay, moving right along. So we've talked about here's how you copy all these different 28 pieces of stuff around all of your different environments but we haven't talked about setting up the environments in the first place. So if you wanna have a development environment, a staging environment, a production environment generally those are three separate Apache virtual hosts that you've gotta create so let's assume your hosting provider gives you a Apache but you've gotta set up those different V hosts. You need to choose domain names to access them by, install your SSL cert, all the things you need to do to set up the virtual host, you've gotta do it three times. You have to make sure right all the PHP extensions are installed in my SQL so you need, whoops let me back up. Remember for one site in three environments you don't have one my SQL database, you have three. Separate username, separate password, separate database name because obviously you don't want your production site and your development site using the same database so you've gotta create three separate databases and then track all of those credentials. Obviously you need to have a code repository somewhere that you sit up, maybe you post your code to GitHub or some other hosted SVN sources and that's fine. If you do that and you want to take the step of having an automatic deployment as we did on DevCloud where when you commit to the master branch it's automatically deployed, then you have to write the integration, maybe GitHub has an API at calls when a commit occurs, different systems work differently. So GitHub will call your server when you make a commit but now you've gotta write the code that listens to that call and then goes and does the automated deploy if you want that. Obviously you have to back up and restore, you have to have a backup method and be able to restore things, you have to monitor the servers, make sure they're up, not crashed and they're performing well. This next one is really important and why the manual in the title is in quotes. After you've created all this stuff you have to know that you can recreate all this stuff in exactly the same way which means it really has to be automated. Marcus actually in his previous session talked about this too, he talked about using Puppet which is the tool we actually use in DevCloud. You need to know that when your server blows up which it will that you can get it back and that it looks exactly the same because if something changed, if you manually maintain your server environment you're gonna change something someday.  Did you remember to document that? Probably not. If you did, do you really wanna have to go manually make all those tweaks again? You really don't. So you need to automate it somehow and again I'm not gonna go into the details but it can be done and there's a lot more. I've given previous talks, David Strauss has given several past excellent talks that are linked to from various DrupalCon talks about how you set up servers to serve Drupal efficiently. It's not easy though there is a lot of information out there for people who wanna do it themselves. So that's the doing it yourself approach. Obviously in DevCloud we build the whole server for you and one of the things we let you do since Cloud Scale was in the talk description is you can resize them. So we just have this little environment, this little part of our UI that shows okay your production environment is running on it on serve six that's handling varnish and your database server and your web server and then in this example I've pressed to the reboot button already so that that little lower form opened up and there's a drop list and you can just say alright I'd like to change my server from its current size to a bigger size or a smaller size. If you're hosting at a different cloud provider or Rackspace or wherever you know a lot of them have this capability as well. You just choose what server size you want but again this only works if the building of your server is completely automated. If you switch for example from a 32 bit instance to a 64 bit instance you can't just reattach the disk. It doesn't work because you've got a different fundamental computing architecture. You need a new root partition so no matter what you end up having to rebuild your machine and if you wanna be able to rescale easily it's got to be automated.  DevCloud supports hourly, you can resize and we just bill it for the hours that you use. So that's how we handle servers. That's most of actually the technical content I have. I just wanted to say that a whole list of people helps me build this product at Aquia and the person I'm most interested now in talking to is you. If this sounds like fun implementing all this stuff please come talk to me, we are definitely hiring and questions. Right, so you have asked the Drupal content staging question. It has its own name because it's so frequent. The question was if you wanna do an update while your user generated content is coming in and then revert your update, what do you do? It's a hard problem, the Drupal community has come up with a variety of solutions to that. None of them are specific actually to anything I've talked about. They work with sort of any of the models for managing the environments. So there's a system called features, capital F features that lets you add and remove functionality like that. There's various content migration, sometimes the changes you wanna push aren't really new code changes, they're new content, a new about page, a new whatever, sort of a static page that's not user generated. So this isn't really the session for those. There's nothing about sort of managing and deploying the environments that's specific to that, which tools you use for your environments. They all work with all of them. So I thought I saw, oh, I guess over here. So the question is I showed using Drush SQL Sync to copy databases, what about running update.php or clearing the cache or the other tasks. So obviously I gave an abbreviated list of the things you need to do. No, Drush SQL Sync doesn't do any of that for you.  Now your cache is clear. DevCloud can automate those tasks for you as well. So, but those are other things that you need to do. What makes, what gets extra interesting is when you're running on multiple servers and you need to push your code and the cache needs to get cleared, but you don't wanna clear the cache until you know the code has been updated everywhere. You know, if you run drush rsync and copy the code and it's one server, all right, great. You know what one server is done. If it's three or four servers, well, either you run, you know, you run drush rsync one at a time, but that means that now your multiple servers are running different versions of the code for the duration of copying it to all of them and then you clear your cache. It can get a little tricky. And that's, you know, those are the things we automate in DevCloud and in Managed Cloud, which is the multi-server version of the product. So yeah, I mean, I was just giving sort of the high-level overview, but there are those other steps you have to do. I couldn't fully hear you. Do it, yeah, okay. Someone else to ask and then I'll get to him as he, when he comes closer. Did I see another hand? Maybe not. Okay, can you shout louder? Wow, I just can't hear. This is why they gave me the portable mic. Okay, the best practice for deploying a hotfix on DevCloud. One moment. So, in that, actually I'll show it right here. In this little change to box that you can drop down, it lists all of your branches and all of your tags. So, if you have a hotfix and you've got a release branch, you can select, let's say, you can select the release branch in your staging environment. Now you're running the release branch there. You can commit your hotfix to that release branch. It will get deployed immediately. Maybe being near two microphones is a mistake. And then drag from staging to production and it will cut a new tag and deploy it. We do that all the time. In fact, just for a little self-referential mind bending, this whole user interface that I've been showing you is part of the Acquia Network. The Acquia Network is a system where we sell subscriptions for managing various aspects, like Drupal sites. The Acquia Network itself is a Drupal site. And not surprisingly, it's running on Acquia Managed Cloud, which is the system. So, the Acquia Network has a subscription for itself as a Drupal site and it has a cloud UI for itself. So, when we wanna deploy updates to the Acquia Network, we commit them to the current branch and then we go to the Acquia Network subscriptions workflow page and drag the staging environment to the production environment and basically the network updates itself using this exact thing. So, we use this all the time. And in fact, sometimes we push out three, four, five fixes a day.  It's terrific. In fact, I've been a developer for 20 some odd years. I'm a total command line guy. I would never have imagined before that I wanted a user interface to push changes out to my website. Before I built this, I would use R-Sync, actually, just sync things up and I had a make file that automated it for me. But, what we have found is that you drag your branch to production. It makes the tag for you. It's so nice that the network engineering team uses it and we use it for all our internal sites. All right, who is the guy who came down so I could hear? Oh, that's an excellent idea. So, some modules create their cache files in the files directory and you have people that upload files. How do you manage that separated? How do you separate those files from each other? Oh, you're asking about if the site owners put files into the files directory. Yes. Don't do that. Really, I say that based on painful experience. The files directory with Drupal is for user uploaded files. If you start putting, like if you put theme files or whatever, your own content there, things start getting really ugly. Okay, so I'm gonna back off that a little. If, for example, what you wanna do is, we do this all the time, where we'll put a site on opia.com which has a case study. So we wanna attach a PDF file for it. So that's not, in a sense, that's not user generated content and if we were getting to this guy's question, if we were doing a content staging thing where we put up our case study with the attached PDF in the staging environment and then migrate that to production, then in that case, I would have a file because it was attached via the upload module. That would be in the files directory and that would need to get copied over. That would have to be the job of the content staging solution, whether that was the content migrate module or whatever. You can use R-Sync. So R-Sync, by default, when you copy from a source to a destination, it doesn't delete things in the destination that aren't present in the source. It's additive. So if you copy your production directory down to your staging environment, add a file and copy it back, what you end up with is you've just added, you've added a file to the production environment. In fact, even if you don't copy down to your production environment first, you add a file to staging and copy it up. R-Sync will just add the files. This works because Drupal almost never modifies anything in the files directory. It's pretty much right once.  And that's what I meant by don't do that. The files directory has to be managed purely by Drupal or bad things happen. Because then you're right, there's no way to separate what's a Drupal managed file versus a code managed file in the files directory. If you really need to do that, then just have another directory where you put those files. It's not the Drupal managed files directory. Have it be statics or something. And you can put that in your code repo and commit your static PDFs or whatever it is you want. Does that answer the question? Sort of? Not really? Okay. My question is, support the different DevCloud servers that can sync all the data. I mean, in Europe, USA or Asia, if I have three DevCloud servers, these three servers can sync all the data. Between your accent and the echo, I could not understand a word you said. Try not using the microphone and talk a little louder and I might be able to hear you. My question is, this is a DevCloud server, right? Yes. If I have three different position DevCloud servers like Asia, Europe, and USA, and three different servers, I wanted to support the data between these three servers to synchronize. Can someone translate for me? I'm sorry, I can't understand. Okay. You have three different servers and three different continents. You want to sync the dates? Yes. In these three different position servers. I guess I'm not sure what you mean by sync the dates. But sync the... Oh, synchronize. Oh. Synchronize the date. Like the files or database. You want to sync the clocks on the servers. Yeah, yeah, yeah. There's a system called NTP that pretty much is the universal tool for that. It stands for Network Time Protocol. There's a package for every flavor of Linux. It runs NTPD, that's November Tango Papa Delta. And you give it a time server, which is, you know, there are various time servers running on the network and then all of the servers sync to that. And that's how we do it. That's pretty much how everyone that I know does it is using NTP. It's what kind of weights? I use the public network or the dedicated line to synchronize the date. Can someone, I apologize, I can't understand what you're saying. I mean, what kind of way you can to sync for the different servers date? Why don't you come talk to me afterwards? The echo is killing me. So, we'll talk afterwards without the echo. I'm sure I'll be able to understand you. Someone else? I'm not seeing any of their hands. I guess we're done a little early. What, is there more? Sorry, over there. I'm sorry, I just, it's not working. I'll get you next. Hold on, the microphone's over there. What do you do about table locking from the SQL databases? This is unbelievable. I am having the hardest time hearing. Speak slower, let's see if that helps. What are you doing about table locking? Table locking. When you import, so, right, the question is if you run a MySQL dump, then as it reads through each of your tables, it locks them and so for the duration of the MySQL dump, your site basically freezes. This is not a very happy thing. There's two different answers to that. If you're running on a single server, which most of the examples that I was giving were talking about that, your only real option for that is use InnoDB, which is a database engine for MySQL that supports row level locking and more intelligent read-only locking, and it works better. When you do the MySQL dump, you use dash dash single transaction, and it works better. It doesn't lock the whole table. So only thing, so, it takes a read lock. Obviously, honestly, I've been a little wondering about that for a while, why it doesn't freeze the database. I think it takes a read lock that still enables the site to keep working for the duration of, well, it opens a transaction, and so it works the same way transactions do. So the other transactions are able to make commits, but I assume they penned until the first transaction finishes. The summary is use InnoDB and make your dump with single transaction. It's still not perfect. You can still hit a situation where your dump is blocking certain tables. There's not a really great answer if you're using a single database. If you're in an environment where you're running multiple database servers, then you can make your backups off of a slave, which is one of the other alternatives. That's what we do in Managed Cloud. There is a third option, which there is a tool called ExtraDB, ExtraBackup, which I don't remember if it comes from Percona, or if it's, I think it comes from Percona, which is a MySQL consulting shop, that actually makes your database, makes a non-locking database dump off of the live database. It begins a transaction, it does non-blocking reads, it makes a copy, and then it goes and reads the bin log, the journal for any changes that have occurred since it started and updates those into the backup. So when you're done, instead of having a MySQL dump file, or a text file with all your SQL, you have an actual copy of the MySQL directory, which you can then point a MySQL server at and make a dump from that because no one's reading from it. It's an extra level of hassle. We used ExtraDbBackup or whatever it's called for a while, we found it didn't work that great, which was surprising because the guy who recommended it to us is excellent and has always known everything he's ever talked about before, but that tool didn't work very well for us. Maybe we were using an older version and it's better now. So if you are on a single server and you can't withstand the InnoDB MySQL dump, then ExtraBackup is the next best choice. Hello Drupal or hello Kitty Drupal. Sure, what he's talking about, Drush has a ton of features. Drush is an awesome tool, everyone should use it. We use it all the time. He's talking about with the Drush SQL dump. So I showed Drush SQL sync, which logs into one server, does a dump, logs into the other and loads it up. It's composed out of smaller components and one of them is the Drush SQL dump, which just gives you the MySQL dump and it has options, which I assume sync inherits, which lets you, first of all, you can select which tables or ignore certain tables, like if you don't wanna copy your search index from production to staging because it just takes too long, you can skip it. You can also say, don't give me any data, just give me the table structures and copy those across. But I'm not sure what, other than for a performance enhancement, what was, right, right. So you can ignore certain tables. The MySQL dump command has these options.  You can give it a list of tables and it passes it onto MySQL dump. And so it will either ignore them completely or what he is recommending is before you do your full copy, you can do a copy just of the table structures, right, just the create tables statements. Those are very fast. You do that for all your tables so that you end up with like an empty cache table and empty search index. And then you do a second copy where you ignore those tables completely so they don't get deleted in the destination but you don't copy the database either. So when you're done, you have all of your tables but only the ones you care about actually have data just to save time during the copy. Okay, oh, one more. Hey, is there any partial sync options like we have a database which is quite large, a lot of nodes and on our dev environments, we don't really need all the data just like the freshest amount of it. So is it possible to get like only the last 50K of nodes using DevCloud or how would you go and know about it? All I could make out was is it possible to get the last set of, I don't know, could someone, I apologize for the echo. Okay, okay, so the question was and it was much easier here without the microphone. Is it possible to copy only say the last 50K or the last some subset of tables? It's not an option DevCloud has and I don't know if it's an option MySQL Dump has. It's an interesting question, I haven't thought about it. It's an interesting request. I'll look at that. If there is an easy way to do it, then sure we can put it in because it does take a while to copy databases. Yes, so the question is about scrubbing your database. After you copy production to staging and now you wanna run a test but you don't want email to go out to all of your site visitors. Obviously doing it the manual ways, you have to start, you have to write your own scrub. You know what tables you have that have data that you wanna remove. So assume you've written an SQL script or something that does that. Obviously with the command line or Drushways you can just run that SQL statement. What we are going to be adding in DevCloud we have not yet is in your code repository next to where your Docker root is, next to where all your code is, we're gonna have a directory which is the, I'm not sure what we're gonna call it yet but it's like the deploy directory. And within that there will be a subdirectory named after each of your environments so DevStage and prod. And within that will be a list of scripts that when you do a deploy to an environment it will then run each of those scripts in order until one fails. Until one exits with non-zero status. So in your staging environment you could put your scrub script there. In your production environment maybe you sends you an email that says you just deployed to production or whatever you wanna do. That's been on our backlog for a little while. We're planning to do it before the end of the year. We just haven't gotten to it yet. We have a lot of things on the list. But it is coming. We need that internally. As I said we do, we have a staging and production environment for networks.acquia.com and we actually had a pre, before we even built cloud we had a system for scrubbing the databases and whatever. And our network engineering team is like hey when are you gonna get that done? Cause we'd really like to use it so. Coming soon. The question is if you've got a very busy live site and you have some new code and you wanna test the new code against your current database and I assume the reason you're saying busy live site is you don't wanna slow down your live site by making a backup in order to do this test. I'm sure, well let me, this will be, oh I seem to have, I'm not projecting anymore.  So with any of the solutions I demonstrated, you can run the SQL sync or you can use devcloud drag and drop to just copy. Okay, so this is another variation of the content staging problem.  Is that your question? Right, right, right. I mean the real problem there is that you've got, you've got configuration changes in your beta site that maybe you put there by clicking in the UI and building up a new view or whatever. And again that's the Drupal content staging problem. We really need a solution for extracting configuration state from user generated content. That's one of Dries's main initiatives for Drupal 8. In the absence of a good solution for that, if you're not using the features module or the other various approaches to solving that problem, then what you were suggesting is you have your staging site, you copy the database down, then you push your code, you start by copying your database down, then you make your changes to it. If you're making your changes by hand, you're sort of in a world of hurt, but you then push your new code, you test it out. What you were then suggesting is, okay now I just swap which environment is which. That's actually an interesting idea. DevCloud doesn't support that. I didn't talk about that in my talk. It's changing the roles of your environments. There's no particular reason we don't support that. I just never come up. In our environment what you would do is copy your database down, push your code into staging, push your code, sorry, copy your database to staging, push your code to staging, test out your changes. Hopefully your changes are, any database changes are code driven either by features or update functions or whatever. Then push your code to live and make those changes. If the changes you're making are manually clicking on the UI, then the approach I just described means you gotta go manually click on the UI again in production which is a problem and why we need a content staging solution or configuration staging solution. Okay, I think I am out of time. So thank you very much.


Hi, everyone. I'm going to talk about lossiness and tropic hardness for ring LWE. I'm Tzvika and this is joint work with Nico Duttling So let's start by talking about the learning with errors problem Which I'm sure a lot of you have heard about learning with errors is essentially the problem of solving a system of approximate Random linear equations modular q. So let's be a little more concrete. So we have this matrix a that I have on the slide This is a short and wide matrix n by m using my notation and think of M as some polynomial in N And this matrix is uniform modular q. Q is going to be some global modulus That's going to remain unspecified in the talk it actually ranges from being polynomial in N to being exponential in N But you can just think about this being some large polynomial in N for the purpose of the talk So we have this random matrix a and this gets multiplied by a secret vector s and s is also uniform modular q Now this product s times a To that we add a noise vector e. So e is a vector of IID elements And these are sampled from a noise distribution Which is supported only over elements that are much much smaller than q in absolute value and this s a plus e Mod q is denoted by b. This is going to be the outcome of this system of linear equations Approximately linear equations and the learning with errors problem in the search version Is the problem of given a and b to find the values of the variables of the system of equations s And there's also the decision version which is also going to be important for us And this is the problem of distinguishing a and b from a and u where u is just a uniform Vector that has nothing to do with s and e And again as many of you probably know Learning with errors has been super useful for cryptography. It has a simple linear algebraic structure That allows to use it very easily and provides strong security properties Such as presumed post quantum security and worst case to average case hardness reductions And this makes it an invaluable tool for a building block for many cryptographic Many cryptographic constructions. However, in many cases lwe is not efficient enough to be used In schemes that are designed for the real world And for this this purpose in order to improve efficiency, there are variants of lwe That rely on algebraic number theory and they provide greater efficiency in particular the ring lwe problem Is such a variant and this is going to be the focus of this work and also of this talk However, in order to make everybody's life easier, there's not going to be any algebraic number theory in the talk Rather, we're going to present an abstraction that will allow us to To talk about these algebraic algebraic number theory variants without Without thinking about polynomial rings and things of this sort We call our abstraction structured lwe and it goes as follows. So at first I'm just going to change the notation Rather than thinking about a as one Wide matrix I'm going to partition it into square blocks a1 a2 and so forth And I'm also going to partition the vector e and the vector b into chunks accordingly So now rather than thinking about lwe as finding s given a and b I can think about it as the problem of finding s given A collection of pairs a i and b i and likewise I can also define the decision version In a similar manner. So now I can say that in standard lwe it's Standard lwe is a structured lwe problem where the distributions of the a i is uniform and of the e is is gaussian But now I can start playing with the problem by changing the distributions of the a i and e i and thus get the different variants So the ring lwe problem, which is the focus of this work and also the related polynomial lwe problem Can be presented also as structured lwe But now rather than the a i being uniform the a i is drawn from a distribution that represents Multiplication by a random ring element and since ring multiplication is a bilinear operation This can actually be represented as a matrix where matrix multiplication represents the multiplication over the ring And these this class of matrices actually forms a multilinear group, which is going to be important for us The vectors e i are still going to be gaussians, but they're not going to be iad gaussians They can be slightly weird gaussians According to the geometry of the ring, but this is not going to matter much for us for the purpose of the talk So this allows us to define ring lwe In the form of structured lwe which is what we need for for this work and for the talk But let me just point out that there are other variants of lwe that can be thought of using the subtraction For example, module lwe middle product lwe in order lwe are also cases where the multiplication It's an lwe variant where the multiplication is this Has this bilinear form and can therefore be represented by matrix multiplication So we don't make use of this and it makes use of this in this work But this could be interesting to think about independently In this work we study entropic hardness for ring lwe But let's start by talking about entropic hardness for structured lwe in general So not distinguished between the different flavors and the question here is what happens when s is not sampled from a uniform distribution But rather rather from some other distribution and the first question I guess is why should we even care? So one case where this could be useful is that of leakage resilience So sometimes s is used as a secret key for some Cryptographic scheme and we can consider a case where an adversary obtains some partial information about s So the distribution of s now in the eyes of the adversary is no longer uniform and the question is whether the scheme remains secure another case is that Sometimes for example in fully homomorphic encryption using a different distribution for s gives you better functionality as well as better efficiency And in that case, for example, it is sometimes useful to sample s from a binary distribution rather than a uniform distribution and this sort of Leads us to the distributions that we should care about in the in the context of entropic lwe so Of course, it's obvious that the distribution has to have sufficient entropy non-trivial entropy Otherwise the lwe problem is obviously not hard And and we could care about Small or binary distributions for s so s is sampled now uniformly over the entire domain But only over elements that are small or only over binary elements And the other case is sort of general entropic distributions where we don't know what the exact distribution is But all we know is that it has sufficient entropy All right, so now that we hopefully care, uh, what is the answer? Is the problem still secure or not? Well for standard lwe there is a sequence of of known results Essentially establishes hardness for small and binary Distributions and recently also for general entropic distributions. So this is good However, for wringled lwe almost nothing is known and i'm going to go back to this almost later on And the question is why like why can we not why can we not since these problems are so similar? Why can we not uh, sort of translate the techniques from the lwe regime to hold also for wringled lwe? So let's start by going over the main ideas that allow us to prove entropic hardness for standard lwe And actually all of these works that are mentioned here uses the same basic idea Which is to rely on lossiness in order to prove entropic hardness So what is this idea? So the idea is to replace the ai with a different distribution Which is still going to be computationally distinguishable But this new distribution is going to be over matrices that are going to lose some information about s in this multiplication process And this is going to help in improving entropic hardness as we will see in a minute In particular the distribution that is that is normally used is to replace the ai by essentially an lwe instance by itself So we're going to sample a global uniform matrix b And as you can see b is going to be a very narrow matrix It's going to have the same number of rows as ai, but it's going to be very narrow and it's going to be universal There's only going to be one b in the system. It's not going to be a bi And now for each i we're going to sample sample a ci Which is going to be a matrix of the appropriate dimensions so that b times ci has the same dimension as ai So it's so b times ci is going to be a square matrix And ci is going to be a random and secret matrix and to that we're going to add f fi Which is just a matrix of iid noise just as in Just as an lwe and the lwe assumption the decisional version of lwe Actually asserts that this distribution is going to be computationally indistinguishable from the uniform distribution Which is the prescribed distribution of the ai so we can make the substitution And and still remain computationally indistinguishable from the original from the original distribution Now let's see why making the substitution actually helps improving entropic hardness So from this point and on the argument is going to be information theoretic So we're going to show that once we replace the distribution of the ai's Even the computationally unbounded adversary is not able to recover Is not able to recover the value of s given these samples So let's see what kind of information The adversary can actually learn about s when it is given s times ai plus ai and also of course ai by itself So let's see what we know about what we what an adversary an unbounded adversary can learn about s So the first thing that the adversary learns is this value s times b so and This just uh, this term just appears in all of the whenever you have s times ai you get s times b times ci plus s times fi so s times b is a value that potentially leaks However, since the since b is a very narrow matrix s times b has a very Small dimension and therefore s times b does not leak a lot of information about s. So this is a bounded amount of information The second thing that is leaked is all these terms of the form s times fi and I also want to add to that the ei that also that also exists in this because this is actually going to be important um, so once So given given s times b and s times fi plus ei This is actually all of the information that an unbounded adversary can learn about s from from these from these samples and This is where sort of all of these approaches that we have here diverge how to deal with s times fi plus ei and what i'm going to describe here this uh, um approach as approach we had in the previous work with nico where we had this technique that we called um, um Flooding that we called flooding at the source and uh, what we what we did there was the following So we said, um, we considered the noise ei so the the noise from the lw sample And we actually showed that you can pull some from this gaussian ai you can pull a smaller gaussian and push it back Before the fi so this distribution s times fi plus ei is actually statistically identical to distribution where you take s Add to add add a gaussian e prime to s Take the sum of these two things multiply that by fi and then add some e double prime i And know that the e prime is just a global value. It does not depend on i only the e double prime depend on i And this means that even a computationally unbounded adversary cannot obtain more information about s Then it then can be obtained from s plus e prime because you never sort of see s naked You can you can only see it with the addition of with the addition of e prime And this led us to define this notion of noise loss in s Which is the amount of information on s, which is sampled from some some distribution Which is lost when you add gaussian noise to it And what we what we showed was that this noise lossiness actually sort of dictates The entropic hardness of the lwe problem that you have So you have the the lossiness that comes from the noise lossiness And on the other hand you have this additional sort of side information that Comes from this s times b and so long as s times b does not give you sufficient information To sort of recover from the noise lossiness Then you're going to have entropic hardness Because the adversary is not going to be able to recover the original s And we see that noise lossiness we can see that noise lossiness actually has Sort of the properties that we would expect when we talk when we talk about entropic hardness So first of all the more entropy that s has the better noise lossiness it is going to have And intuitively think about it This actually means that the distribution of s is sort of more dense in the space of all possible s's And this means that when we when we add gaussian noise to it It is more likely to get confused between some value of s and some neighboring value of s Likewise if s has smaller euclidean norm This is also going to be better because again now this smaller norm means that this space of possible s's is smaller It's just going to be this small ball that contains all the elements With with small norm and therefore again if you add gauss if you add a gauss into it You're sort of still sort of dense in this ball And therefore it is more likely for you to get confused between a given s and a neighboring s lastly Notice that the Gaussian parameter of the noise e i is also going to matter because the amount of e prime that we are able to sort of pull back Through the fi is actually going to depend on the amount of noise in the e i that we have So the larger the noise in the lwe Sample that you have the better parameters you're going to get for For the entropic for the entropic hardness which also makes sense So this is the notion of noise lossiness and This sort of is one way to sort of address the problem in the context of standard lwe However, if you try to apply it to ring a lwe you see that you run into a problem and the reason is that What we do here is replace the matrix a i with a matrix Which is close to a low-rank matrix in the sense that This distribution that we have this lwe distribution is a low-rank matrix b times ci. That's a low-rank matrix plus some noise And in fact the the structure of of ring lwe So if we think about as a structured lwe problem, we said that the a i here is going to be Is going to be a ring multiplication matrix and ring multiplication matrix can just cannot have The form of being a low-rank matrix plus some noise So we can just not make the substitution in the context of ring lwe And now perhaps it's the time to talk about this exception So there is one work with bolboceno Perlman and Sharma where we show that in a very specific case So the case where the modular sort of splits completely over the ring and using a very non-standard assumption We can actually get some entropic hardness result for ring lwe and in that particular case You can actually you can think about it as presenting the the a i matrix as sort of low rank plus noise plus low rank low rank plus noise matrix, but this requires A non-standard assumption All right, so let's see how we can get around this problem and actually get lossiness for ring lwe So we said that we wanted to replace a i with a close to low-rank matrix, but we cannot do it So how about trying to be more bold and try to replace a i with a close to zero-rank matrix? So just maybe try to get a i to be computationally distinguishable from a short matrix f i Well, this of course doesn't work because a i is not a short matrix However, we make the observation that what actually matters is the roast pan of f And not f itself So what we're going to do is replace the matrix a i with a matrix that has in its roast pan a short matrix In particular we're going to take a i and replace it with a product h times z i where h is going to be a global big matrix And z i is going to be a short matrix and the roast pan of this matrix actually contains z i Which as we are going to see this is going to give us what we want Now this actually does not offend the structure of the a i as a ring multiplication operation because we can sample h and z i Also as ring multiplication for a ring element So h is going to be for a large ring element and z i is going to be for a short ring element and the product is also going to correspond to A ring multiplication matrix for the corresponding the product of these two ring elements So in terms of structure, we can do this We don't run into the problem that we had before where we were trying to do low rank plus noise So this is already a good thing now We also notice that this is actually Not I mean this is not a new assumption and actually I mean the way that we got to it is actually in the reverse root You can actually present known assumptions such as the entro assumption or d s pr the decisional short polynomial ratio problem as Exactly exactly in this form Where the the h and z i sort of represent That represent ring element multiplication for the appropriate ring elements And we should also notice that this sort of idea we We learned this idea of Replacing a i with say an entro instance was used in a survey in the l w e survey of pie card to relate the hardness of entro With the hardness of ring l w e But we are actually going to use this we are going to show that this can be used in order to show entropic hardness Also notice that the assumption can have many flavors in particular We might want to make we say the z i is short but the question is how short So the shorter z i is the better it is for us the better lossiness we're going to get and this is not surprisingly going to make the assumption stronger However, uh, if we only care about if we only want a mild Mild z i's which are going to be good enough to get some entropic hardness We can actually see that this assumption this d s pr assumption actually converges with ring l w e So we are going to be able to get entropic hardness Not the strongest possible results But by just assuming the ring l w e problem itself, uh, but if we want the sort of stronger, um If we want stronger entropic hardness, we need to make stronger assumptions such as d s pr All right, let's see what information about s a computationally unbounded adversary can deduce after we make the substitution Of h of ai with h times z i So note that an unbounded the adversary gets the gets to see all the ai's and therefore it can Derive h out of it. So h is not secret to an unbounded adversary So the unbounded adversary what it sees is s times h times z i plus e i for a bunch of ai's And again, we're going to use the technique of flooding at the source And we're going to pull out of the e i, uh, the this addition this noise term e prime such that we can write, uh, the S h z i plus e i as well We have this term in a bracket s times h plus e prime where e prime is global All of this gets multiplied by z i and then you get some additional you add some additional e double prime i Um, but once we do this we notice that all the information about s is actually contained inside the brackets So actually all the adversary all an unbounded adversary learns about s is this term s times h plus e prime So, um, the fact that it's a sequence of elements and so forth is not going to matter for us for now from now on And when we look at this we see that this already gives us some flavor of entropic hardness So we could uh, uh, let's think about defining, um s times h noting it by s prime So what we have in the bracket is uh, s h plus e prime. So this is actually s prime plus e prime And we notice now that if s prime has good noise lossiness, then we get entropic hardness Why is that? Well if s prime has high noise lossiness Then this means that the computationally unbounded adversary cannot derive s prime From seeing s prime plus e prime However, since h is just a global invertible matrix This means that if you cannot if the adversary cannot deduce s prime, then it also cannot deduce s So if s prime has high noise lossiness, then we are in good shape Um, and this is already useful because again since multiplying by h is an invertible transformation The entropy of the distribution of s prime is going to be the same as the entropy of distribution of s And since we know that all high entropy distributions are going to have well pretty good noise lossiness, then If we know that s has sufficiently high entropy Then this means that even though we don't know h s prime Is whatever h is s prime is also going to have sufficiently high entropy and therefore it's going to have pretty good noise lossiness So this already gives us um some uh entropic hardness for general entropic distributions However, what we want is to relate the entropic hardness to the noise lossiness of s itself Which will allow us to get better results. For example, this will allow us to um get better results for s with uh with low norm Which is sort of the ultimate result that we want to get a result that is comparable to what we know In the standard lw e setting So let's recap um the information that an unbounded adversary has about s is s times h plus e prime And we want to somehow relate this to the noise lossiness of s itself. So remember the noise lossiness Is what information about s is lost when you just add um Gaussian noise to s not to s to s times h So in order to um in order to do that We recall additional property of the n true or d s pr assumptions And actually this is this can be derived without loss without loss of generality from the assumption the way we described it So you can assume without loss of generality That the inverse of h mod q is a matrix z zero which is a short matrix by itself So this is a global matrix and it's going to be short. Uh, and we're going to be able to use this property In order to derive our sort of ultimate result So let's see how so we know that mod q The inverse of h is a short matrix. So this means that we can take this entire Equation that we have we have s h plus e prime and multiply it by z zero Now, let's see what happens when we multiply by z zero Well, the h cancels out and know that this whole thing is done module q.  It's not exactly the Gaussian that we want So e prime is like A nice a nice Gaussian. So you can think about this continuous or Being over the integers. However, after you multiply by z zero What you get is a Gaussian over the lattice that is defined by the rows of z zero because well, you get a linear combination of the rows of z zero and This is not the Gaussian that we that we have in the definition of noise lossiness Um and furthermore We need to take into account that this Gaussian can be sort of very far from being spherical So it depends on the properties of z zero. So actually what we need to do is uh, Sort of conditioned on the case where z zero has sort of nice singular values So that e prime times z zero is a Gaussian over the lattice z zero Which is close to being spherical And in order to do that we need to define a notion that is called sometimes lossiness We show that this holds with some non negligible probability But not necessarily probability close to one and we show that this is uh, this actually suffices in order to show Entropic hardness. So this is an additional technical difficulty. Uh, but let me not get into the details So going slightly back, uh, we have s plus e prime times z zero And e prime times z zero is a Gaussian over the lattice z zero. So let's try to sort of see how this Um, how this expression relates to the expression of noise lossiness Where noise lossiness is just how much information about s is lost when you just add like, you know, a standard Gaussian not a Gaussian over a lattice So, um, how much information about s is leaked with a Gaussian over a lattice? Well, we notice that you can notice that you are going to get more information than what you get from the standard noise lossiness because in particular we can take this expression, uh, s plus e prime times z zero and Sort of reduce it modular the lattice itself So we can check which coset of the lattice is zero this expression This expression belongs to and the coset of the lattice is zero of this expression is the same as the coset of this Is the same as the cost of z zero of s itself. So the cost of s within the lattice z zero Is something that can be deduced from s plus e prime times z zero and cannot And cannot be deduced if we just added sort of standard Gaussian noise to s So, uh, we get something we get some additional leakage on top of what sort of the noise lossiness tells us that we're that we're going to get so, um what we have here is that To conclude from this expression the information about s that we lose is the noise lossiness. Well, here it says plus but actually minus The information that is contained in the coset of s. So you lose the information in the noise loss in the noise lossiness and possibly gain The information that is obtained in the coset of s. So if the noise but if the noise lossiness is large enough to actually, um Sort of compensate for this additional Information that is contained in the coset then we're going to be in good shape So we have this interest that To choose the parameters so that the lattice z zero has as few cosets as possible What does it mean to have a few to have a few cosets as possible? That the lattice z zero needs to be as dense as we can as dense as we can make it Which sort of translates to the matrix z zero being as short as we can make it So the the shorter, uh, the the smaller the elements of z zero are the fewer cosets that it's going to have And this sort of makes sense, right because the better results the the because well a smaller z zero Sort of translates to into as making a stronger hardness assumption So in order to get better and tropic results, we need to make a stronger hardness assumption Which sort of makes sense. So, um, if we make a stronger and stronger hardness assumption We can, um, make z zero smaller and smaller and make this lost this loss that comes from the coset Again smaller and smaller Annoyingly we cannot take z zero to be small enough So as to allow us to use binary distribution on s So the leakage from the coset is large enough, uh, so that no matter, um, sort of within reasonable parameters We cannot get the noise loss in s to be good enough To compensate for it when s is a binary when s is a binary distribution simply because a binary distribution Cannot have that much entropy. It cannot it can only have n bits of entropy So the question of entropic wringled we with a binary secret still remains open Um, however, we did manage to relate, uh, the entropic hardness of wringled we To this notion of noise lossiness plus this additional loss that comes from the coset of s Which sort of translates the parameters of the, uh, hardness assumption that we are making So this is sort of the ultimate result that we have, uh, in this work All right, let's conclude So what we saw here was that the notion of noise lossiness that was defined previous work in the context of lwe Also implies entropic hardness for the case of wringled we Um, and we need to compensate for this additional loss that comes from leaking the coset of s with respect to some lattice Which is parameterized in the assumption Uh, what is the assumption that we need the hardness assumption that we need to make in order to get entropic hardness? Well, we can rely just on the standard wringled we assumption And this is going to give us, uh, entropic hardness, uh, in the case where we have we initially start from sufficiently High noise lossiness for our secret s and in the case where the noise e i is sufficiently high So this is going to already give us some, uh, um entropic hardness if we want better parameters for entropic hardness We need to make a stronger assumption particular this, uh, uh, decisional short polynomial ratio assumption This is already going to give us entropic hardness for sort of modest, uh, noise lossiness And noise value for for the wringled we instance and for sort of the ultimate parameters If you want binary wringled we we still don't know we still don't know how to get it We don't know how to get our techniques to work for these this parameter regime So this is an interesting open problem. Um, we present this new obstruction structured lwe Um, so we actually thought about this obstruction only For our convenience so that we don't need to sort of work with this algebraic number theory and the entire paper So we wanted to abstract things as much as possible for our own sake But maybe it's an interesting, uh, maybe it's an interesting, um, um, abstraction and maybe it can be useful elsewhere Maybe for example, you can use this to show entropic hardness for other variants of the lwe problem Um And with that I will leave you. Thank you very much