Safe Launcher Dev Issues/Suggestions

Development
1

I have some questions/issues concerning the safe launcher API below. These are too small for an RFC, and possibly too opinionated to be considered bugs.

  1. Can we remove encryption (and thereby base64 encoding on the whole body…still fine in JSON fields)? It serves little purpose for localhost-to-localhost and is not consistent (we encode query params but not paths, we encode the body sometimes, etc). If there is need, we can do X509 certs using TLS to auth/communicate w/ teh safe launcher (though I question whether it’s needed)
  2. Cannot retrieve public NFS files uploaded with demo app in another app (uses app key). What is the reason for this considering I can get them via the DNS API (but I can’t get sub directory listings there)? Is this related to “safe drive access”?
  3. Please add logging on errors (and maybe even access logs)…I know it’s a bit of a hassle when also handling things like rotation, but it’s worth it
  4. Please follow HTTP conventions on:
  5. Content-Disposition instead of “file-name” and “file-created-time”
  6. Content-Length instead of “file-size”
  7. Last-Modified instead of “file-modified-time”
  8. 404 when a file is not found
  9. 4xx when the error is my fault instead of 500
  10. Currently 500’ing when I use my JWT on things that don’t need it
  11. Consider having the NFS API accept a path at the end like the DNS API does instead of encoding the path (e.g. with slashes encoded) and having a boolean at the end. If you need to separate “shared” and not shared, I say that’s two separate path prefixes not a boolean’d-string suffix
  12. Isn’t a NACL nonce meant to change per message?
  13. Be more clear about the error format. Sometimes it encrypts, sometimes not
  14. “file-metadata” header is “undefined” instead of properly empty
  15. Do y’all have a responsible disclosure policy on security bugs?
  16. If y’all had to guess, how much time would I be wasting coding against the current API (meaning, how much do y’all think it will change)?
  17. If the maidsafe dev team had to suggest to a dev which entrypoint to use to build his app, would they say launcher API, FFI lib, or direct to Rust libs?

I came across these things (and more) when toying w/ my API client at GitHub - cretz/go-safeclient: CLI and Go library for accessing SAFE network and I am unsure whether it’s worth the effort of codifying all the quirks (e.g. checking for a specific error code from the JSON that comes from the FFI just to check not found) or if I am just coding against this prematurely and should just stop and wait.

Thanks.

7 Likes
2

I feel like jumping into a running train here - my knowledge about recent changes may not be as up-to-date as @Krishna_Kumar’s so hopefully if i understand anything wrong it will be promptly corrected. I’ll attempt a few questions nonetheless.

At the network level, we do not depend on nonce to prevent replay attacks. There are other forces at play to prevent that - group consensus, message filters etc. At the core to app boundary, it’s supposed to be symmetric cipher. Here you can view Nonce as IV (Key-IV pair which remains unchanged once exchanged). There is no protection against replay attack here and i don’t think it is necessary to code for it at this interface (front-end app ↔ launcher).

This should be in place after a next few merges - the PR is already sitting in safe_ffi - that should hopefully log to both the console and to a log-file

I wouldn’t see that as wasting time. For one i believe it is not going to change meteorically. Secondly everything is open to the community - so if there are ppl who feel very strongly against current design and can discuss a convincingly better alternative then the development will take a new course. I think that’s a good thing and a natural way for any open and community involving development.

This again depends. What kind of app, what do you want to target etc. Normally one would develop against the Launcher. But there is absolutely no stopping for someone directly interfacing with any of MaidSafe’s libraries to code anything one thinks would be useful. That’s just like developing in other environments - your needs would be very different if you were writing an antivirus program than if you were designing a simple text editor.

6 Likes
3

Yeah, we do have few issues. We were on a short sprint to get the first version out. We would be stabilising in the sprint to follow.

But we are addressing few issues that you have highlighted here and should be merged to the master sooner.

Saw this point in the RFC that you had raised, I hope this gets discussed there in detail.

The root directory of the user will have a SAFEDrive folder created by default. And every application will get its own directory, when the user authorises the application for the first time. Applications will be able to access only data within their own folder. In addition they can access SAFEDrive with users consent (app request for the SAFE Drive permission).

There is a variable isPathShared in most of the APIs exposed from launcher. This indicates whether the path is shared from SAFEDrive or within the application directory itself. This variable simply gives the launcher the root directory to search for the directory or file.

This is where you are seeing a problem, while trying to read another applications data

Yes, this is currently being worked on. The next update to the master branch should have the logs printed on the console and in packaged mode the log file will be generated next to the binary.

I will try content-disposition header, wont that make the browser download the content instead of rendering it. I will give a try for sure.

file-size header refers to the actual file size. We can get smaller chunks of data using the API by specifying the offset and length. So the actual content transferred would be in the Content-Length while the actual file size is present in the file-size header

500 error is removed and 404 is added, this should be reflected in the next update to the master branch.

I see a issue there. Will stabilise it. When there is some unhandled exception the error messages are not encrypted.

Should be resolved in the next update to master branch

The suggested approach would be through the launcher.

6 Likes
4

Thank you very much for the responses…

Makes sense (though I propose dropping local encryption anyways).

It might be better to be at the API level instead of the FFI level since some things don’t make it there (e.g. auth).

I think I might end up being one of those people.

Good deal. I figured that Maidsafe would like to avoid people sharing their three factor auth on a bunch of apps.

Thanks for the responses, now to the one below… :slight_smile:

1 Like
5

Good deal. I want to mention that I am not against app authentication (i.e. the JWT) and I feel it is probably required to tie app keys to safe calls for rewards (among other things).

Fantastic info, thanks. May I ask a favor then? Can you make the “/public/” stuff coming out of the demo app in the save drive instead of the demo-app-specific folder? Right now nobody can write an app to access that stuff unless they cheat and lie about who they are (like I did at https://github.com/cretz/go-safeclient/blob/4bb564456103f36eb254e0049b65c5474f3806a1/cmd/root.go#L24 :slight_smile: )

Yes, that can happen if it is set as attachment. I have not looked into it very deeply. Granted if I requested it I probably know the name anyways.

As for file sizes and partial content, you should look into Content-Range and 206 statuses (partial content).

Other stuff understood. Thanks again for the feedback. It is very helpful IMO that we can engage on the tech details here.

4 Likes