Re: [Nix-dev] Persistent NixOps keys

That's probably it! I still need to update all service configs to have keys.target in the wantedBy list. I read somewhere that I should also use requiredBy for it to really wait untill keys.target is finished.. Kind regards, Erik On Thu, Jun 16, 2016, 23:50 Игорь Пашев

Re: [Nix-dev] Malicious installation methods

>> The installer, when run, will fetch more code for users to blindly >> execute (as most of that code will be provided in compiled form). How >> is blindly running an installer worse than running other code from >> the same provider? > > Simply put the shasum of your installer on the website and

Re: [Nix-dev] Malicious installation methods

>> I ask you to PLEASE remove this installation method from the >> recommendations on the page because it makes it look like you don't >> care about computer secuirty one bit. > > Now, that's an interesting point. Are there many people who never > installed nix because the installer is the

[Nix-commits] [NixOS/nix] e95f3c: Fix test

Branch: refs/heads/master Home: https://github.com/NixOS/nix Commit: e95f3c44435c9f4540f684b7a9bdaecda8f3740a https://github.com/NixOS/nix/commit/e95f3c44435c9f4540f684b7a9bdaecda8f3740a Author: Eelco Dolstra Date: 2016-06-17 (Fri, 17 Jun 2016)

[Nix-commits] [NixOS/nixpkgs] bec28d: Remove unecessary branching on old nix versions

Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: bec28d748c854abda373ca38831f4e77bc276fc1 https://github.com/NixOS/nixpkgs/commit/bec28d748c854abda373ca38831f4e77bc276fc1 Author: zimbatm Date: 2016-06-17 (Fri, 17 Jun 2016)

Re: [Nix-dev] Malicious installation methods

> The installer, when run, will fetch more code for users to blindly execute > (as most of that code will be provided in compiled form). How is blindly > running an installer worse than running other code from the same provider? Simply put the shasum of your installer on the website and ask the

Re: [Nix-dev] Malicious installation methods

On 17/06/16 09:17, Adrien Devresse wrote: >> The installer, when run, will fetch more code for users to blindly execute >> (as most of that code will be provided in compiled form). How is blindly >> running an installer worse than running other code from the same provider? > > Simply put the

Re: [Nix-dev] User-oriented nixpkgs documentation (was: ioquake3 on nixos)

Write a blog post. Though it is hard to maintain blog post content over time, ask yourself "how long am I able to maintain this knowledge? Who should be responsible for verifying this manual in with future changes?" People expect manuals to be consistent with software. Every time I find errors in

Re: [Nix-dev] Malicious installation methods

>> But without even considering that, "curl-pipe-bash" will cause your >> sysadmin to blow a fuse or heartbreak in most companies / environments. >> And for very good reasons. > > That is not very different from a "make install" of a downloaded tarball, > though. :) The fact that when you build

Re: [Nix-dev] Malicious installation methods

> Like already said before, detecting if a user run a curl-pipe-bash and > injecting a malicious binary on the fly is rather trivial to do compared > to compromise the nixos website itself, and create a phising to fake > both the tarball and the displayed hash. Hash would only ensure that there

Re: [Nix-dev] Malicious installation methods

> So you're trusting a hash from the same site that you are downloading > the script from? I can see a lot of value in a cryptographic signature > (like PGP) but I see almost no value in a hash. > Briefly, yes. This is already a security improvement. Like already said before, detecting if a user

[Nix-dev] [y...@cock.li: Re: Malicious installation methods]

>> Retrieving code straight from the internet and blindly executing is >> never a good thing and you don't give any sort of recommendation for >> the user to inspect the script before running it. This completely >> defeats the point of having reproducible builds when your system can >> be

Re: [Nix-dev] Malicious installation methods

On Fri, Jun 17, 2016 at 03:17:59PM +0200, Adrien Devresse wrote: > But without even considering that, "curl-pipe-bash" will cause your > sysadmin to blow a fuse or heartbreak in most companies / environments. > And for very good reasons. That is not very different from a "make install" of a

[Nix-commits] [NixOS/nixpkgs] 4ac742: perl-IO-Socket-SSL: 2.020 -> 2.027

Branch: refs/heads/release-16.03 Home: https://github.com/NixOS/nixpkgs Commit: 4ac7425f18534a4dd0f135b3c3cf043da9b5163c https://github.com/NixOS/nixpkgs/commit/4ac7425f18534a4dd0f135b3c3cf043da9b5163c Author: Robert Helgesson Date: 2016-06-17 (Fri, 17 Jun

[Nix-commits] [NixOS/nixpkgs] 980960: perl-IO-Socket-SSL: fix default path to SSL certs

Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: 98096004ce316969e3b4494d102c1fb172b7e474 https://github.com/NixOS/nixpkgs/commit/98096004ce316969e3b4494d102c1fb172b7e474 Author: Robert Helgesson Date: 2016-06-17 (Fri, 17 Jun 2016)

[Nix-commits] [NixOS/nixpkgs] 8fccaa: disnix-module: split dysnomia's functionality into...

Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: 8fccaa901192be95f75412f12f54063196b18186 https://github.com/NixOS/nixpkgs/commit/8fccaa901192be95f75412f12f54063196b18186 Author: Sander van der Burg Date: 2016-06-17 (Fri, 17 Jun

Re: [Nix-dev] Persistent NixOps keys

Hi Tomasz, Thanks for another great pointer! My own services do require the keys so I have to make them depend/require on keys.target I'm about to test this out, I'll keep you posted here.. Kind regards, Erik On Fri, Jun 17, 2016, 11:47 Tomasz Czyż wrote: > Erik, you

[Nix-commits] [NixOS/nixpkgs] 420b3c: git: fix perl shebangs in contrib

Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: 420b3c37ef65b04ca3a84eda3d952f8b2152cd97 https://github.com/NixOS/nixpkgs/commit/420b3c37ef65b04ca3a84eda3d952f8b2152cd97 Author: Alexey Lebedeff Date: 2016-06-16 (Thu, 16 Jun

[Nix-commits] [NixOS/nixpkgs] af412f: disnix-module: split dysnomia's functionality into...

Branch: refs/heads/release-16.03 Home: https://github.com/NixOS/nixpkgs Commit: af412f29c817f0789998b495e369c8abaebcda38 https://github.com/NixOS/nixpkgs/commit/af412f29c817f0789998b495e369c8abaebcda38 Author: Sander van der Burg Date: 2016-06-17 (Fri,

Re: [Nix-dev] Persistent NixOps keys

Erik, you also could add your load-keys service to network.target or any target which starts at the system start. So then you don't have to add it to specific apps, depends on your keys workflow. 2016-06-17 9:48 GMT+01:00 4levels <4lev...@gmail.com>: > That's probably it! > > I still need to

[Nix-commits] [NixOS/nixpkgs] 95b896: gvolicon: c04cafb -> 31cf770

Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: 95b896228dfd560b76ed149ed80e12f15c60bd2f https://github.com/NixOS/nixpkgs/commit/95b896228dfd560b76ed149ed80e12f15c60bd2f Author: Benno Fünfstück Date: 2016-06-17 (Fri, 17

Re: [Nix-dev] Malicious installation methods

Hi, On 06/17/2016 08:01 PM, Yui Hirasawa wrote: >> True, of course. But, there is a class of software projects which will >> likely never be "packaged" by package managers - namely, other package >> managers. Nix falls into this class, along with, for example, NPM, >> Brew, Oh-My-Zsh, and

Re: [Nix-dev] [y...@cock.li: Re: Malicious installation methods]

>>> Assuming a MITM it's already game over here, the MITM doesn't even >>> have to control one of the CAs. >> >> No. If you are verifying the GPG signature it is not game over. It >> doesn't matter how you retrieve the signature and the signed file if >> you verify them, this is assuming that the

Re: [Nix-dev] Malicious installation methods

On 17 June 2016 at 11:42, Yui Hirasawa wrote: >> I ask the members of the list to point to a software project that is >> doing this > > Any software project that is telling the user to install the software > using the package manager of their distribution. Pretty much all package >

Re: [Nix-dev] Malicious installation methods

>>> I ask the members of the list to point to a software project that is >>> doing this >> >> Any software project that is telling the user to install the software >> using the package manager of their distribution. Pretty much all package >> managers verify signatures and they are really

[Nix-commits] [NixOS/nixpkgs] ed46b4: Fix Travis build failure caused by Qt/KDE document...

Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: ed46b468b09dd0a44450b7df348e6a572a424529 https://github.com/NixOS/nixpkgs/commit/ed46b468b09dd0a44450b7df348e6a572a424529 Author: Thomas Tuegel Date: 2016-06-17 (Fri, 17 Jun 2016)

Re: [Nix-dev] Malicious installation methods

>>> True, of course. But, there is a class of software projects which will >>> likely never be "packaged" by package managers - namely, other package >>> managers. Nix falls into this class, along with, for example, NPM, >>> Brew, Oh-My-Zsh, and others. >> >> What reason would there to not package

Re: [Nix-dev] Rework goPackages

Hi Kamil, First thank you for working on this! Having go2nix as a tool certainly makes packaging Go programs much easier! I don't do a lot of Nix packaging but I do write Go software---so maybe I have a different perspective on this. Anyhow here are some thoughts: - Many Go software projects try

Re: [Nix-dev] Malicious installation methods

> True, of course. But, there is a class of software projects which will > likely never be "packaged" by package managers - namely, other package > managers. Nix falls into this class, along with, for example, NPM, > Brew, Oh-My-Zsh, and others. What reason would there to

[Nix-commits] [NixOS/nixpkgs] 6b02ae: pptpd: init at 1.4.0

Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: 6b02ae3893dda3e22fe375694bfb8d5ff317be0c https://github.com/NixOS/nixpkgs/commit/6b02ae3893dda3e22fe375694bfb8d5ff317be0c Author: obadz Date: 2016-06-18 (Sat, 18 Jun 2016) Changed

Re: [Nix-dev] Malicious installation methods

>>> True, of course. But, there is a class of software projects which will >>> likely never be "packaged" by package managers - namely, other package >>> managers. Nix falls into this class, along with, for example, NPM, >>> Brew, Oh-My-Zsh, and others. >> >> What reason

[Nix-dev] Link to nix.useSandbox in pull request template

I've encountered a missing dependency in a package, and created a pull request [1] to add the dependency. However, I'm not completely sure how to build/test this using sandboxing as is suggested in the pull request template. Could the link to the documentation be broken? Thanks, Maarten [1]

Re: [Nix-dev] Link to nix.useSandbox in pull request template

On Sat, Jun 18, 2016, at 12:03 AM, Maarten Hoogendoorn wrote: > I've encountered a missing dependency in a package, and created a pull > request [1] to add the dependency. > > However, I'm not completely sure how to build/test this using sandboxing > as > is suggested in the pull request

Re: [Nix-dev] Malicious installation methods

On 06/18/2016 12:00 AM, Yui Hirasawa wrote: >> > Because it invalidates all the store references. > Seems like nix needs some redesign then. It's also the upstream packages... most of them require absolute paths to locate their files, and I don't blame them as IMHO that approach saves some

Re: [Nix-dev] Malicious installation methods

>>> Is the nix root dir configurable? Would it be that horrible to have >>> /opt/nix or /var/lib/nix or something else be the nix root on Debian? >> >> It's not strictly required, but it would mean losing out on all the binary >> packages provided by the CI. > > Aren't they built in a chroot like

[Nix-commits] Success: Hydra job nixpkgs:trunk:tarball on x86_64-linux

Hi, The status of Hydra job ‘nixpkgs:trunk:tarball’ (on x86_64-linux) has changed from "Failed" to "Success". For details, see https://hydra.nixos.org/build/36902589 This may be due to a commit by Thomas Tuegel . Yay! Regards, The Hydra build daemon.

Re: [Nix-dev] Malicious installation methods

On Fri, Jun 17, 2016, at 11:36 PM, Yui Hirasawa wrote: > > True, of course. But, there is a class of software projects which will > > likely never be "packaged" by package managers - namely, other package > > managers. Nix falls into this class, along with, for example, NPM, > >

Re: [Nix-dev] Malicious installation methods

First of all, you can install nix in another location, but then you won't be able to use the binary cache anymore. I thought a bit about how we could make this work: - store the nix store physically in /var/lib/nix/store on Debian - create a union fs in /var/lib/nix/nix-root of / and

Re: [Nix-dev] [y...@cock.li: Re: Malicious installation methods]

On 17/06/16 10:26, Eelco Dolstra wrote: > > Cargo cult security is not a priority. I wouldn't worry about "curl | bash" > but > not the giant binary tarball downloaded and executed by that script (or > equivalently, installing a binary RPM or Deb package). Signing the installer > script would

Re: [Nix-dev] [y...@cock.li: Re: Malicious installation methods]

>> HTTPS is not a verified channel. Our current CA system is really >> fragile > > It is, but it works a lot better than the PGP web of trust in that it > doesn't require people to get together to engage in quaint key signing > rituals. PGP has a web of trust but in our CA anyone with

Re: [Nix-dev] [y...@cock.li: Re: Malicious installation methods]

> I agree with this. A key that is trusted itself (rather then trusting a > domain name) would be a very large security increase. I agree too. And this more or less the way taken by RPM / DPKG that ship their trusted key on the client side when you install a new repository instead of relying on

Re: [Nix-dev] Rework goPackages

On 06/17/2016 12:55 PM, Kamil Chmielewski wrote: > few days ago I started a PR called [WIP] Rework goPackages > https://github.com/NixOS/nixpkgs/pull/16017 which is now on master and > can leads toconfusion for everyone creating goPackages before. If that's so, a note should go to --Vladimir

[Nix-commits] [NixOS/nixpkgs] a34ec6: terra: 2016-01-06 -> 2016-06-09

Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: a34ec656594a01dcddc1e121f23d60b14aed835a https://github.com/NixOS/nixpkgs/commit/a34ec656594a01dcddc1e121f23d60b14aed835a Author: William Casarin Date: 2016-06-16 (Thu, 16 Jun 2016)

Re: [Nix-dev] Malicious installation methods

On 17 June 2016 at 11:12, zimbatm wrote: > Pretty good SSL: https://www.ssllabs.com/ssltest/analyze.html?d=nixos.org > > I wonder if something like this would be better perceived: I ask the members of the list to point to a software project that is doing this (providing

Re: [Nix-dev] Malicious installation methods

> I ask the members of the list to point to a software project that is > doing this Any software project that is telling the user to install the software using the package manager of their distribution. Pretty much all package managers verify signatures and they are really convenient for the

Re: [Nix-dev] Malicious installation methods

Hi, On 06/17/2016 03:02 PM, Ertugrul Söylemez wrote: > For marketing reasons it may be beneficial to attach a security note to > that command, such that people understand why it's really not any less > secure than other methods. Alternatively get rid of the pattern and > distribute a bunch of

Re: [Nix-dev] [y...@cock.li: Re: Malicious installation methods]

Hi, On 06/17/2016 03:56 PM, Yui Hirasawa wrote: > HTTPS is not a verified channel. Our current CA system is really fragile It is, but it works a lot better than the PGP web of trust in that it doesn't require people to get together to engage in quaint key signing rituals. > Here is a quote

Re: [Nix-dev] [y...@cock.li: Re: Malicious installation methods]

On 17/06/16 10:33, Yui Hirasawa wrote: > >> Signing the installer script would provide only a minor increase in >> security (in that it would require the signing key to be compromised, >> rather than the nixos.org certificate). I don't object to doing that >> though. > > That is quite a major

Re: [Nix-dev] [y...@cock.li: Re: Malicious installation methods]

On Fri, 17 Jun 2016 at 16:35 Jookia <166...@gmail.com> wrote: > On Fri, Jun 17, 2016 at 03:01:00PM +, zimbatm wrote: > > I don't mean to say that GPG is a bad idea. It just that using SSL is a > > better idea unless we nail the GPG bit. Not everyone is getting > > state-sponsored attacks. > >

Re: [Nix-dev] [y...@cock.li: Re: Malicious installation methods]

On Fri, Jun 17, 2016 at 03:01:00PM +, zimbatm wrote: > I don't mean to say that GPG is a bad idea. It just that using SSL is a > better idea unless we nail the GPG bit. Not everyone is getting > state-sponsored attacks. TLS and GPG aren't mutually exclusive, you can use both. It's also worth

Re: [Nix-dev] [y...@cock.li: Re: Malicious installation methods]

On Fri, 17 Jun 2016 at 16:18 Yui Hirasawa wrote: > > Assuming a MITM it's already game over here, the MITM doesn't even have > to > > control one of the CAs. > > No. If you are verifying the GPG signature it is not game over. It > doesn't matter how you retrieve the signature and

[Nix-commits] [NixOS/nixpkgs] a2b19f: libinput: 1.3.1 -> 1.3.2

Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: a2b19f46608b53d03b61adf4f2e7c2c136e3184a https://github.com/NixOS/nixpkgs/commit/a2b19f46608b53d03b61adf4f2e7c2c136e3184a Author: Alexander Ried Date: 2016-06-17 (Fri, 17 Jun 2016)

[Nix-commits] [NixOS/nixpkgs] f7ab8f: openjdk: 8u92b14 -> 8u102b04

Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: f7ab8f80a0c2c5a0e9462adac9a10c770fe88219 https://github.com/NixOS/nixpkgs/commit/f7ab8f80a0c2c5a0e9462adac9a10c770fe88219 Author: Tim Steinbach Date: 2016-06-16 (Thu, 16 Jun 2016)

Re: [Nix-dev] Malicious installation methods

Pretty good SSL: https://www.ssllabs.com/ssltest/analyze.html?d=nixos.org I wonder if something like this would be better perceived: sudo mkdir /nix curl https://nixos.org/$(arch)nix.tar.gz | sudo tar -C /nix xvfsudo /nix/post-install Or I wonder if there was a universal script that would wrap

Re: [Nix-dev] Malicious installation methods

On Fri, 17 Jun 2016 at 15:19 Yui Hirasawa wrote: > >>> Like already said before, detecting if a user run a curl-pipe-bash and > >>> injecting a malicious binary on the fly is rather trivial to do > compared > >>> to compromise the nixos website itself, and create a phising to fake

[Nix-commits] [NixOS/nixpkgs] 592dcb: Fix evaluation error in Qt/KDE packages

Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: 592dcbc4bfbdd98ee2f22bdea1b895db337cb770 https://github.com/NixOS/nixpkgs/commit/592dcbc4bfbdd98ee2f22bdea1b895db337cb770 Author: Thomas Tuegel Date: 2016-06-17 (Fri, 17 Jun 2016)

Re: [Nix-dev] [y...@cock.li: Re: Malicious installation methods]

> Assuming a MITM it's already game over here, the MITM doesn't even have to > control one of the CAs. No. If you are verifying the GPG signature it is not game over. It doesn't matter how you retrieve the signature and the signed file if you verify them, this is assuming that the crypto

[Nix-commits] [NixOS/nixpkgs] 75b460: Cantata: update homepage (#16296)

Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: 75b460ce1b00678105f67c4e57c81952446edd6e https://github.com/NixOS/nixpkgs/commit/75b460ce1b00678105f67c4e57c81952446edd6e Author: emosenkis Date: 2016-06-17 (Fri, 17 Jun 2016)

[Nix-dev] Wake from Suspend MacBook Air 2015 Causes Backlight to Turn Off

I've tested this issue in Gnome3 and XMonad (without a DE) with the same results - suspending to mem (manually with "sudo rtcwake -m mem -s 20" in Gnome as closing the laptop lid appears to only put the computer in standby mode - an explanation for its uncharacteristically quick resume time when

Re: [Nix-dev] Raspberry-Pi NixOS

2016-06-15 15:01 GMT+03:00 Matthias Beyer : > Hi viric, > Hi dezgeg, > > I just found the wiki page on nixos on the raspberry[0], where you two are > referenced as creators. That page is quite old, https://nixos.org/wiki/NixOS_on_ARM has some newer stuff. Though the ARMv7

[Nix-commits] [NixOS/nixpkgs] fcf72b: DisnixWebService: 0.5 -> 0.6

Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: fcf72b82ae386bc83fd9a4bd7ed253e22ad30078 https://github.com/NixOS/nixpkgs/commit/fcf72b82ae386bc83fd9a4bd7ed253e22ad30078 Author: Sander van der Burg Date: 2016-06-17 (Fri, 17 Jun

[Nix-commits] [NixOS/nixpkgs] ca97cc: DisnixWebService: 0.5 -> 0.6

Branch: refs/heads/release-16.03 Home: https://github.com/NixOS/nixpkgs Commit: ca97cce179b3a4106d0ec6f3560333cdf764cef5 https://github.com/NixOS/nixpkgs/commit/ca97cce179b3a4106d0ec6f3560333cdf764cef5 Author: Sander van der Burg Date: 2016-06-17 (Fri,

[Nix-dev] Rework goPackages

Hi, few days ago I started a PR called [WIP] Rework goPackages https://github.com/NixOS/nixpkgs/pull/16017 which is now on master and can leads to confusion for everyone creating goPackages before. I was also a little surprised how fast it was merged but I thought it was the effect of how many

[Nix-commits] [NixOS/nixpkgs] 552388: diff-so-fancy: init at 0.9.3

Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: 552388f8dfd185e603b2cfd6ef54696bbbd5 https://github.com/NixOS/nixpkgs/commit/552388f8dfd185e603b2cfd6ef54696bbbd5 Author: Alexey Lebedeff Date: 2016-06-17 (Fri, 17 Jun

Re: [Nix-dev] Malicious installation methods

On 17/06/16 07:12, Yui Hirasawa wrote: > > Retrieving code straight from the internet and blindly executing is > never a good thing and you don't give any sort of recommendation for the > user to inspect the script before running it. This completely defeats > the point of having reproducible

[Nix-dev] Malicious installation methods

I recently noticed that you recommend very malicious installation methods on your download page for nix[1] Retrieving code straight from the internet and blindly executing is never a good thing and you don't give any sort of recommendation for the user to inspect the script before running it.

[Nix-commits] [NixOS/nixpkgs] 2efdaa: xmonad-wrapper: link man pages of xmonadEnv

Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: 2efdaa948d2fcbcd37f952bb1a18c65316d5010a https://github.com/NixOS/nixpkgs/commit/2efdaa948d2fcbcd37f952bb1a18c65316d5010a Author: Benno Fünfstück Date: 2016-06-17 (Fri, 17

[Nix-commits] [NixOS/nixpkgs] 03e3ef: xmonad-wrapper: link man pages instead of copying

Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: 03e3ef6234ff6ff4bc02f70c7c44c0a06249d14e https://github.com/NixOS/nixpkgs/commit/03e3ef6234ff6ff4bc02f70c7c44c0a06249d14e Author: Benno Fünfstück Date: 2016-06-17 (Fri, 17

Re: [Nix-dev] Malicious installation methods

simple as that, just don't do it. https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-bash-server-side/ On 17 Jun 2016 12:38, "Kevin Cox" wrote: > On 17/06/16 07:12, Yui Hirasawa wrote: > > > > Retrieving code straight from the internet and blindly executing is > >

Re: [Nix-dev] Malicious installation methods

Dnia 17 czerwca 2016 13:12:57 CEST, Yui Hirasawa napisał(a): >I recently noticed that you recommend very malicious installation >methods on your download page for nix[1] > >Retrieving code straight from the internet and blindly executing is >never a good thing and you don't give

Re: [Nix-dev] Malicious installation methods

On 17/06/16 07:59, Azul wrote: > simple as that, > just don't do it. > > https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-bash-server-side/ > While this is interesting research I find that it is often irrelevant because you are trusting the server anyways. So if you trust the server