default images.fix.orientation to false

1 files changed, 0 insertions, 51 deletions

diff --git a/note/security.txt b/note/security.txt
deleted file mode 100644
index 59ac52bd2..000000000
--- a/note/security.txt
+++ /dev/null
@@ -1,51 +0,0 @@
-Design for SeaweedFS security
-
-Design Objectives
-	Security can mean many different things. The original vision is that: if you have one machine lying around
-	somewhere with some disk space, it should be able to join your file system to contribute some disk space and
-	network bandwidth, securely!
-
-	To achieve this purpose, the security should be able to:
-	1. Secure the inter-server communication. Only real cluster servers can join and communicate.
-	2. allow clients to securely write to volume servers
-
-Non Objective
-	Multi-tenant support. Avoid filers or clients cross-updating files.
-	User specific access control.
-
-Design Architect
-	master, and volume servers all talk securely via 2-way SSL for admin operations.
-	upon joining, master gives its secret key to volume servers.
-	filer or clients talk to master to get secret key, and use the key to generate JWT to write on volume server.
-	A side benefit:
-		a time limited read feature?
-	4. volume server needs to expose https ports
-
-HTTP Connections
-	clear http
-		filer~>master, need to get a JWT from master
-		filer~>volume
-	2-way https
-		master~ssl~>volume
-		volume~ssl~>master
-
-file uploading:
-	when volume server starts, it asks master for the secret key to decode JWT
-	when filer/clients wants to upload, master generate a JWT
-		filer~>volume(public port)
-		master~>volume(public port)
-
-Currently, volume server has 2 ip addresses: ip and publicUrl.
-	The ip is for admin purpose, and master talk to volume server this way.
-	The publicUrl is for clients to access the server, via http GET/POST/DELETE etc.
-		The write operations are secured by JWT.
-	clients talk to master also via https? possible. Decide on this later.
-
-Dev plan:
-	1. volume server separate admin from public GET/POST/DELETE handlers
-		The step 1 may be good enough for most use cases.
-
-	If 2-way ssl are still needed
-	2. volume server add ssl support
-	3. https connections to operate on volume servers
-