Files
zooqueen dd74d3e6d6 Replace AGPL MinIO fork with Apache-2.0 SeaweedFS fork; rebrand CLI weed->s3
hanzoai/s3 was an AGPL-3.0 MinIO fork whose network-copyleft blocks embedding
and reselling as a managed service. Replace it wholesale with a fork of
SeaweedFS (github.com/seaweedfs/seaweedfs, Apache-2.0, Go) which ships a
built-in S3 gateway + Filer.

- License: AGPL-3.0 -> Apache-2.0 (upstream LICENSE kept verbatim, incl.
  "Copyright 2025 Chris Lu"); NOTICE added crediting SeaweedFS. No AGPL/BUSL/
  SSPL/GPL or enterprise ("ee") files remain.
- Module: go.mod path set to github.com/hanzoai/s3 with a self-replace
  (replace github.com/seaweedfs/seaweedfs => ./) so the ~1800 internal Go files
  keep their upstream import paths with zero churn. Internal identifiers and
  import paths are intentionally NOT renamed.
- CLI rebrand: the binary is built as `s3` (was `weed`); root usage, per-command
  help/usage/flag strings, shell autocomplete program name, and the product name
  in CLI output now read "Hanzo S3" / `s3`. Users never see `weed`.
  (e.g. `s3 server`, `s3 filer`, `s3 master`, `s3 volume`, `s3 s3`, `s3 mount`.)
- Build: `make` (or `go build -o s3 ./weed`) builds the `s3` binary green;
  `cmd/weed-db` and `cmd/weed-sql` also build; `go vet ./weed/command/` clean.
- README/LLM.md rewritten for Hanzo S3; AGENTS.md/CLAUDE.md symlinks preserved.
- Dropped a 33MB prebuilt Mach-O `stress` binary upstream had committed; `.gitignore`
  updated to ignore the `s3` build output.
2026-06-18 23:41:25 -07:00

33 lines
1.2 KiB
Go

package s3_constants
// Cryptographic constants
const (
// AES block and key sizes
AESBlockSize = 16 // 128 bits for AES block size (IV length)
AESKeySize = 32 // 256 bits for AES-256 keys
// SSE algorithm identifiers
SSEAlgorithmAES256 = "AES256"
SSEAlgorithmKMS = "aws:kms"
// SSE type identifiers for response headers and internal processing
SSETypeC = "SSE-C"
SSETypeKMS = "SSE-KMS"
SSETypeS3 = "SSE-S3"
// S3 multipart upload limits and offsets
S3MaxPartSize = 5 * 1024 * 1024 * 1024 // 5GB - AWS S3 maximum part size limit
// Multipart offset calculation for unique IV generation
// Using 8GB offset between parts (larger than max part size) to prevent IV collisions
// Critical for CTR mode encryption security in multipart uploads
PartOffsetMultiplier = int64(1) << 33 // 8GB per part offset
// KMS validation limits based on AWS KMS service constraints
MaxKMSEncryptionContextPairs = 10 // Maximum number of encryption context key-value pairs
MaxKMSKeyIDLength = 500 // Maximum length for KMS key identifiers
// S3 multipart upload limits based on AWS S3 service constraints
MaxS3MultipartParts = 10000 // Maximum number of parts in a multipart upload (1-10,000)
)