py1815 0.1.0__tar.gz
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- py1815-0.1.0/.gitignore +23 -0
- py1815-0.1.0/CHANGELOG.md +164 -0
- py1815-0.1.0/CONTRIBUTING.md +115 -0
- py1815-0.1.0/LICENSE +202 -0
- py1815-0.1.0/NOTICE +10 -0
- py1815-0.1.0/PKG-INFO +161 -0
- py1815-0.1.0/README.md +130 -0
- py1815-0.1.0/SECURITY.md +105 -0
- py1815-0.1.0/docs/DESIGN.md +646 -0
- py1815-0.1.0/docs/assets/ASSETS.txt +21 -0
- py1815-0.1.0/docs/assets/dersec-dark.png +0 -0
- py1815-0.1.0/docs/assets/dersec-white.png +0 -0
- py1815-0.1.0/docs/assets/satori-dark.png +0 -0
- py1815-0.1.0/docs/assets/satori-mark-dark.png +0 -0
- py1815-0.1.0/docs/assets/satori-mark.png +0 -0
- py1815-0.1.0/docs/assets/satori.png +0 -0
- py1815-0.1.0/docs/dnp3.md +249 -0
- py1815-0.1.0/docs/index.md +74 -0
- py1815-0.1.0/docs/outstation.md +166 -0
- py1815-0.1.0/docs/reference/control.md +7 -0
- py1815-0.1.0/docs/reference/events.md +6 -0
- py1815-0.1.0/docs/reference/objects.md +6 -0
- py1815-0.1.0/docs/reference/protocol.md +19 -0
- py1815-0.1.0/docs/reference/server.md +7 -0
- py1815-0.1.0/docs/reference/session.md +6 -0
- py1815-0.1.0/docs/testing.md +75 -0
- py1815-0.1.0/pyproject.toml +104 -0
- py1815-0.1.0/src/py1815/__init__.py +74 -0
- py1815-0.1.0/src/py1815/application.py +501 -0
- py1815-0.1.0/src/py1815/control.py +473 -0
- py1815-0.1.0/src/py1815/crc.py +68 -0
- py1815-0.1.0/src/py1815/events.py +326 -0
- py1815-0.1.0/src/py1815/link.py +294 -0
- py1815-0.1.0/src/py1815/objects.py +401 -0
- py1815-0.1.0/src/py1815/py.typed +0 -0
- py1815-0.1.0/src/py1815/server.py +406 -0
- py1815-0.1.0/src/py1815/session.py +1549 -0
- py1815-0.1.0/src/py1815/transport.py +141 -0
- py1815-0.1.0/tests/test_application.py +358 -0
- py1815-0.1.0/tests/test_control.py +294 -0
- py1815-0.1.0/tests/test_control_parsing.py +154 -0
- py1815-0.1.0/tests/test_events.py +513 -0
- py1815-0.1.0/tests/test_link.py +289 -0
- py1815-0.1.0/tests/test_objects.py +393 -0
- py1815-0.1.0/tests/test_server.py +550 -0
- py1815-0.1.0/tests/test_session.py +388 -0
- py1815-0.1.0/tests/test_session_confirmation.py +634 -0
- py1815-0.1.0/tests/test_session_controls.py +789 -0
- py1815-0.1.0/tests/test_session_events.py +438 -0
- py1815-0.1.0/tests/test_session_fragment_budget.py +448 -0
- py1815-0.1.0/tests/test_session_fragmentation.py +730 -0
- py1815-0.1.0/tests/test_session_fragmentation_invariants.py +223 -0
- py1815-0.1.0/tests/test_session_provider_blocks.py +343 -0
- py1815-0.1.0/tests/test_session_unsolicited.py +182 -0
- py1815-0.1.0/tests/test_transport.py +175 -0
py1815-0.1.0/.gitignore
ADDED
|
@@ -0,0 +1,23 @@
|
|
|
1
|
+
__pycache__/
|
|
2
|
+
*.py[cod]
|
|
3
|
+
*.egg
|
|
4
|
+
*.egg-info/
|
|
5
|
+
dist/
|
|
6
|
+
build/
|
|
7
|
+
.venv/
|
|
8
|
+
.mypy_cache/
|
|
9
|
+
.pytest_cache/
|
|
10
|
+
.ruff_cache/
|
|
11
|
+
.coverage
|
|
12
|
+
htmlcov/
|
|
13
|
+
|
|
14
|
+
# Build output of the interoperability Rust master.
|
|
15
|
+
interop/rust-master/target/
|
|
16
|
+
|
|
17
|
+
# Artifacts the interoperability sweep writes.
|
|
18
|
+
sweep.pcap
|
|
19
|
+
sweep.json
|
|
20
|
+
suricata-out/
|
|
21
|
+
|
|
22
|
+
# Built documentation site.
|
|
23
|
+
site/
|
|
@@ -0,0 +1,164 @@
|
|
|
1
|
+
# Changelog
|
|
2
|
+
|
|
3
|
+
Notable changes to this project, newest first. Versions follow
|
|
4
|
+
[semantic versioning](https://semver.org/spec/v2.0.0.html): while the major
|
|
5
|
+
version is `0`, a minor bump may carry a breaking change and the release note
|
|
6
|
+
says so explicitly.
|
|
7
|
+
|
|
8
|
+
## [Unreleased]
|
|
9
|
+
|
|
10
|
+
Nothing yet.
|
|
11
|
+
|
|
12
|
+
## [0.1.0] - 2026-09-29
|
|
13
|
+
|
|
14
|
+
First release. The protocol stack, the listener, the event path and controls;
|
|
15
|
+
unsolicited responses and the point-map loader are not in it. The API is not
|
|
16
|
+
stable, and while the major version is `0` a minor bump may carry a breaking
|
|
17
|
+
change.
|
|
18
|
+
|
|
19
|
+
### Added
|
|
20
|
+
|
|
21
|
+
- **The protocol stack**: CRC-16/DNP, FT3 data link framing with a stream
|
|
22
|
+
reader, transport segmentation and reassembly, the application layer's
|
|
23
|
+
control octet, function codes, internal indications and object headers, and
|
|
24
|
+
static binary and analog inputs with their quality flags. Each layer is
|
|
25
|
+
testable without the ones above it, and the session does no I/O at all -- it
|
|
26
|
+
takes the octets that arrived and returns the octets to send -- so behavior
|
|
27
|
+
is pinned against literal frames rather than against a socket.
|
|
28
|
+
- **The listener**: TCP and TLS, with an explicit peer allow-list by subject
|
|
29
|
+
name or certificate fingerprint. One master association at a time; admission
|
|
30
|
+
is serialized, and a peer that fails authorization changes nothing about the
|
|
31
|
+
association already established.
|
|
32
|
+
- **An interoperability suite of implementations that are not this one.** Four
|
|
33
|
+
across three jobs, chosen so that no two are the same codebase in different
|
|
34
|
+
clothes: a C++ master through its Python bindings, a Rust master by different
|
|
35
|
+
authors that checks the quality octet and the object variation the C++
|
|
36
|
+
bindings discard, and Wireshark and Suricata reading a capture of the whole
|
|
37
|
+
function code sweep and verifying every checksum in it. The unit suite is
|
|
38
|
+
this library marking its own homework; these jobs are the part that is not.
|
|
39
|
+
- **Event buffers for classes 1, 2 and 3**, with deadbands, overflow reporting
|
|
40
|
+
and confirmation handling. A deadband is measured against the last value
|
|
41
|
+
*reported*, not the previous reading, so a point drifting in steps smaller
|
|
42
|
+
than the deadband is still eventually reported rather than never. A quality
|
|
43
|
+
change generates an event whatever its magnitude, because a point that goes
|
|
44
|
+
comm-lost holding the same number has changed in the way that matters most. A
|
|
45
|
+
full buffer drops its oldest event and says so.
|
|
46
|
+
- **Event object encoding**: the timed and untimed variations of groups 2 and
|
|
47
|
+
32, the six-octet timestamp, and index-prefixed event blocks. Events are not a
|
|
48
|
+
range -- they are whichever points changed, in the order they changed -- so
|
|
49
|
+
each carries its own index.
|
|
50
|
+
- **The event path: a master can now read what the buffers hold.** A read naming
|
|
51
|
+
classes 1, 2 or 3 is answered from them, class 0 still reaches the read
|
|
52
|
+
provider, and an integrity poll naming both gets one response with the events
|
|
53
|
+
in front -- a master applies a fragment in order, so a static value written
|
|
54
|
+
after the events that led to it leaves the point where it should end up.
|
|
55
|
+
|
|
56
|
+
Events are not consumed by being read. They leave the buffer when the master
|
|
57
|
+
confirms the response carrying them, so a response that never arrives has not
|
|
58
|
+
taken the only copy with it, and a master that reads twice without confirming
|
|
59
|
+
sees the same events twice. A confirmation retires exactly the events its
|
|
60
|
+
sequence number covers; one naming any other sequence retires nothing. A
|
|
61
|
+
request repeated under the same sequence is replayed octet for octet rather
|
|
62
|
+
than rebuilt, so the confirmation that follows acknowledges what was actually
|
|
63
|
+
sent.
|
|
64
|
+
|
|
65
|
+
The class and overflow indication bits are derived from the buffers on every
|
|
66
|
+
response rather than tracked beside them, so a bit cannot drift from what is
|
|
67
|
+
waiting. Overflow is retired when the master acknowledges the read that
|
|
68
|
+
reported it -- including a read that carries the bit and no events, which
|
|
69
|
+
would otherwise be a report nothing could ever clear. Other responses report
|
|
70
|
+
the overflow without asking to be confirmed, since a refusal or a write is not
|
|
71
|
+
where an acknowledgement belongs and the next read is what retires it.
|
|
72
|
+
- **A ceiling on the size of a response, and on the work of building one.** A
|
|
73
|
+
master sizes its receive buffer to the fragment size it advertises, so a
|
|
74
|
+
response past it is discarded rather than merely long. A control request whose
|
|
75
|
+
echo would not fit is refused *before* anything is dispatched, since a control
|
|
76
|
+
that executes and cannot report is worse than one that never ran.
|
|
77
|
+
|
|
78
|
+
The ceiling bounds the work too. A small response over a large buffer costs
|
|
79
|
+
the response rather than the buffer.
|
|
80
|
+
- **An answer too large to send at once is a conversation.** The outstation
|
|
81
|
+
sends what fits, the master confirms it, and the next fragment follows under
|
|
82
|
+
the next sequence number until the last one says so. A confirmation is
|
|
83
|
+
therefore the thing that draws out a continuation, which is the only case
|
|
84
|
+
where this outstation answers something that is not a request.
|
|
85
|
+
|
|
86
|
+
No list of unsent events is carried between the fragments. Each is built from
|
|
87
|
+
the buffers as they then stand, so an event evicted while a master was slow is
|
|
88
|
+
gone rather than sent from a list that outlived it, and one recorded meanwhile
|
|
89
|
+
joins the answer rather than waiting for the next -- until the static data
|
|
90
|
+
starts going out, after which the response takes no more events and they wait
|
|
91
|
+
for the one after it.
|
|
92
|
+
|
|
93
|
+
That needs a bound instead of a rule about which events belong where: a device
|
|
94
|
+
that records faster than its master confirms would otherwise never be finished
|
|
95
|
+
with, so a response carries at most sixteen fragments of events and the
|
|
96
|
+
indication bits go on asking for the rest.
|
|
97
|
+
|
|
98
|
+
A master that loses a fragment repeats the confirmation before it and is sent
|
|
99
|
+
that fragment again. Without it the exchange stops dead -- the master waiting
|
|
100
|
+
for something that will never arrive, the outstation for a confirmation that
|
|
101
|
+
will never come.
|
|
102
|
+
|
|
103
|
+
Static data travels at the end rather than being reserved for in every
|
|
104
|
+
fragment, which would have held back a fragment's worth of readings for a body
|
|
105
|
+
arriving several round trips later.
|
|
106
|
+
- **A provider may say where its own objects end.** `ReadProvider` keeps `read`,
|
|
107
|
+
which answers in octets and stays the contract; beside it a provider may
|
|
108
|
+
implement `read_blocks` and have its static data spread across the fragments
|
|
109
|
+
of a response. Without it a point map too large for one fragment is refused,
|
|
110
|
+
and a class 0 poll over roughly 290 analog points already exceeds what a
|
|
111
|
+
master typically advertises. This library still divides nothing: the split
|
|
112
|
+
points are the provider's, and a single block too large to send is refused as
|
|
113
|
+
a whole body would be.
|
|
114
|
+
- **`DISABLE_UNSOLICITED` is answered rather than refused.** An outstation that
|
|
115
|
+
sends no unsolicited responses is already in the state the request asks for,
|
|
116
|
+
so refusing it answered a question the master did not ask. `ENABLE_UNSOLICITED`
|
|
117
|
+
is still refused, which is the honest answer while nothing is sent.
|
|
118
|
+
- **Controls: this outstation commands as well as reports.** `SELECT`,
|
|
119
|
+
`OPERATE`, `DIRECT_OPERATE` and `DIRECT_OPERATE NO ACK`, over control relay
|
|
120
|
+
output blocks and analog output setpoints, with the output status points a
|
|
121
|
+
master reads back afterwards. Given no control provider it still refuses every
|
|
122
|
+
one, which is the truthful answer for an outstation that monitors rather than
|
|
123
|
+
a degraded version of one that commands.
|
|
124
|
+
|
|
125
|
+
Each control is answered on its own: a request naming four points where one is
|
|
126
|
+
unsupported returns four objects with three successes and one refusal, rather
|
|
127
|
+
than one verdict for the fragment. A request that cannot be parsed is refused
|
|
128
|
+
whole instead, because a status has to be attached to an object and a
|
|
129
|
+
truncated body may leave none.
|
|
130
|
+
|
|
131
|
+
Select-before-operate holds the request it was given rather than the points
|
|
132
|
+
that accepted it, since the operate a master sends next is the request it
|
|
133
|
+
already sent. Matching compares the octets, which is exact and sidesteps the
|
|
134
|
+
fact that two NaN setpoints never compare equal.
|
|
135
|
+
|
|
136
|
+
### Changed
|
|
137
|
+
|
|
138
|
+
- **`DIRECT_OPERATE NO ACK` executes rather than being dropped.** The standard
|
|
139
|
+
defines it as function code 5 without a response, and it was previously
|
|
140
|
+
discarded unexecuted -- correct for an outstation that could not command, and
|
|
141
|
+
the worst available behavior for one that can, since a master would believe it
|
|
142
|
+
had issued commands that were silently thrown away. It stays silent, including
|
|
143
|
+
when its body does not parse: a master that asked for no response is not
|
|
144
|
+
listening for a parse error either.
|
|
145
|
+
- **A displaced connection is now aborted; a connection closed at shutdown still
|
|
146
|
+
closes gracefully.** The two callers want opposite things. A displaced peer is
|
|
147
|
+
typically one whose socket died without a FIN, where a graceful close waits on
|
|
148
|
+
TCP retransmission -- under the admission lock, which would let a dead master
|
|
149
|
+
hold the association through a second door. A master connected at shutdown is
|
|
150
|
+
usually healthy, and aborting would discard a response already queued.
|
|
151
|
+
- **Every no-response function code is met with silence before it is parsed**,
|
|
152
|
+
as the standard requires.
|
|
153
|
+
- Quality masks are derived from their own enum per point type, rather than one
|
|
154
|
+
mask built from the analog enum and adjusted by a binary bit. The binary
|
|
155
|
+
chatter-filter bit was previously covered only because it shares `0x20` with
|
|
156
|
+
an analog bit.
|
|
157
|
+
|
|
158
|
+
### Fixed
|
|
159
|
+
|
|
160
|
+
- An event encoder given a timestamp for an untimed variation discarded it
|
|
161
|
+
silently, so the caller believed it had sent a time and the master received an
|
|
162
|
+
event without one. Both directions are now refused.
|
|
163
|
+
- An exception during connection admission escaped without closing the arriving
|
|
164
|
+
socket, leaving a live peer the listener reported as not connected.
|
|
@@ -0,0 +1,115 @@
|
|
|
1
|
+
# Contributing
|
|
2
|
+
|
|
3
|
+
Contributions are welcome -- bug reports, interop findings from real masters,
|
|
4
|
+
and documentation.
|
|
5
|
+
|
|
6
|
+
## Before you write code
|
|
7
|
+
|
|
8
|
+
**For a bug**, open an issue with enough to reproduce it: the master
|
|
9
|
+
implementation you were talking to, the function code and objects involved, and
|
|
10
|
+
the frame bytes if you have them. An outstation is judged by what it puts on the
|
|
11
|
+
wire, so a capture or a hex dump is worth more than a description.
|
|
12
|
+
|
|
13
|
+
**For a feature or a behavior change**, open an issue first. This is a protocol
|
|
14
|
+
implementation, so the useful question is rarely "should we do this" but "what
|
|
15
|
+
does the standard require" -- and that is cheaper to settle before the code than
|
|
16
|
+
after.
|
|
17
|
+
|
|
18
|
+
**For a point map**, the IEEE 1815.2 DER profile's tables cannot ship here: they
|
|
19
|
+
assign specific indices to specific measurements and are distributed to DNP
|
|
20
|
+
Users Group members rather than published, so a library carrying them could not
|
|
21
|
+
be shared. A map for your own device belongs in your project.
|
|
22
|
+
|
|
23
|
+
That prohibition is narrower than "no maps ever". The roadmap plans a map-format
|
|
24
|
+
loader and a published table for the predecessor DER profile, and whether the
|
|
25
|
+
AN2018-001-derived map ships with the first release is an open question in
|
|
26
|
+
[DESIGN.md](docs/DESIGN.md) -- it carries an attribution obligation that needs
|
|
27
|
+
confirming before publication. Neither the loader nor the format exists yet; the
|
|
28
|
+
only interface today is the caller-supplied `ReadProvider`. Open an issue before
|
|
29
|
+
building against either.
|
|
30
|
+
|
|
31
|
+
## Development setup
|
|
32
|
+
|
|
33
|
+
```bash
|
|
34
|
+
git clone https://github.com/DERSecurity/py1815
|
|
35
|
+
cd py1815
|
|
36
|
+
python -m venv .venv && source .venv/bin/activate # Windows: .venv\Scripts\activate
|
|
37
|
+
pip install -e ".[dev]"
|
|
38
|
+
```
|
|
39
|
+
|
|
40
|
+
There are no runtime dependencies, and that is deliberate -- an outstation that
|
|
41
|
+
drags a dependency tree onto an embedded target is harder to justify than one
|
|
42
|
+
that does not. The development extra is `pytest`, `pytest-asyncio`, `ruff` and
|
|
43
|
+
`mypy`.
|
|
44
|
+
|
|
45
|
+
Then:
|
|
46
|
+
|
|
47
|
+
```bash
|
|
48
|
+
pytest -q
|
|
49
|
+
ruff check src tests interop
|
|
50
|
+
ruff format --check src tests interop
|
|
51
|
+
mypy src
|
|
52
|
+
```
|
|
53
|
+
|
|
54
|
+
CI runs all four on Python 3.11, 3.12 and 3.13.
|
|
55
|
+
|
|
56
|
+
## The interop jobs
|
|
57
|
+
|
|
58
|
+
The unit suite is this library marking its own homework: a test that encodes
|
|
59
|
+
with this library and decodes with it agrees with itself through any mistake
|
|
60
|
+
both halves share. The `interop` workflow is the part that does not, and it
|
|
61
|
+
gates every pull request.
|
|
62
|
+
|
|
63
|
+
Four implementations across three jobs, chosen so no two are the same codebase
|
|
64
|
+
in different clothes: a C++ master through its Python bindings, a Rust master by
|
|
65
|
+
different authors, and Wireshark and Suricata reading a capture of the whole
|
|
66
|
+
function code sweep. The masters answer "does it say the right thing"; the
|
|
67
|
+
dissectors answer "is what it put on the wire really DNP3".
|
|
68
|
+
|
|
69
|
+
A change to framing, to object encoding, or to the function codes the outstation
|
|
70
|
+
answers should expect to be caught here rather than by the unit tests. Run it
|
|
71
|
+
locally before pushing if you can -- `interop/` holds the outstation fixture and
|
|
72
|
+
each peer's driver.
|
|
73
|
+
|
|
74
|
+
## What a good change looks like
|
|
75
|
+
|
|
76
|
+
**Tests that could fail.** A test that passes against the broken code tests
|
|
77
|
+
nothing. The check that catches this: revert your fix, confirm the test fails,
|
|
78
|
+
restore it. Assertions shaped like the fixture rather than the behavior are the
|
|
79
|
+
usual way this goes wrong.
|
|
80
|
+
|
|
81
|
+
**Bytes, not round trips.** Protocol tests compare against literal octets --
|
|
82
|
+
`bytes.fromhex` and an explicit expected value. A test that encodes and then
|
|
83
|
+
decodes with the same library proves only that the two halves agree, which they
|
|
84
|
+
will even when both are wrong.
|
|
85
|
+
|
|
86
|
+
**Comments that say why.** What the code does is visible; why it does that
|
|
87
|
+
rather than the obvious thing is not. Where the standard forced your hand, cite
|
|
88
|
+
the clause -- a reference to IEEE 1815 tells the next reader far more than a
|
|
89
|
+
restatement of the line below it.
|
|
90
|
+
|
|
91
|
+
**Type annotations on public API.** `mypy` runs against `src/`. Tests are
|
|
92
|
+
exempt.
|
|
93
|
+
|
|
94
|
+
## How changes land
|
|
95
|
+
|
|
96
|
+
Every change to `main` arrives through a pull request, including the
|
|
97
|
+
maintainers' own. Direct pushes, force pushes and branch deletion are blocked by
|
|
98
|
+
branch protection, with no bypass.
|
|
99
|
+
|
|
100
|
+
A pull request merges when the three test jobs and the `interop` gate are green
|
|
101
|
+
and it carries an approving review. Branches do not have to be up to date with
|
|
102
|
+
`main` first: merging one pull request does not send the others back for a
|
|
103
|
+
rebase, because the peer jobs run against the merge result anyway.
|
|
104
|
+
|
|
105
|
+
## Conventions
|
|
106
|
+
|
|
107
|
+
- Line length 100, enforced by `ruff`.
|
|
108
|
+
- American English in code, comments, and documentation.
|
|
109
|
+
- Commit messages: a short imperative subject, then prose explaining why the
|
|
110
|
+
change is right. No trailers.
|
|
111
|
+
|
|
112
|
+
## Reporting a security issue
|
|
113
|
+
|
|
114
|
+
Please do not open a public issue for a vulnerability. See
|
|
115
|
+
[SECURITY.md](SECURITY.md).
|
py1815-0.1.0/LICENSE
ADDED
|
@@ -0,0 +1,202 @@
|
|
|
1
|
+
|
|
2
|
+
Apache License
|
|
3
|
+
Version 2.0, January 2004
|
|
4
|
+
http://www.apache.org/licenses/
|
|
5
|
+
|
|
6
|
+
TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
|
|
7
|
+
|
|
8
|
+
1. Definitions.
|
|
9
|
+
|
|
10
|
+
"License" shall mean the terms and conditions for use, reproduction,
|
|
11
|
+
and distribution as defined by Sections 1 through 9 of this document.
|
|
12
|
+
|
|
13
|
+
"Licensor" shall mean the copyright owner or entity authorized by
|
|
14
|
+
the copyright owner that is granting the License.
|
|
15
|
+
|
|
16
|
+
"Legal Entity" shall mean the union of the acting entity and all
|
|
17
|
+
other entities that control, are controlled by, or are under common
|
|
18
|
+
control with that entity. For the purposes of this definition,
|
|
19
|
+
"control" means (i) the power, direct or indirect, to cause the
|
|
20
|
+
direction or management of such entity, whether by contract or
|
|
21
|
+
otherwise, or (ii) ownership of fifty percent (50%) or more of the
|
|
22
|
+
outstanding shares, or (iii) beneficial ownership of such entity.
|
|
23
|
+
|
|
24
|
+
"You" (or "Your") shall mean an individual or Legal Entity
|
|
25
|
+
exercising permissions granted by this License.
|
|
26
|
+
|
|
27
|
+
"Source" form shall mean the preferred form for making modifications,
|
|
28
|
+
including but not limited to software source code, documentation
|
|
29
|
+
source, and configuration files.
|
|
30
|
+
|
|
31
|
+
"Object" form shall mean any form resulting from mechanical
|
|
32
|
+
transformation or translation of a Source form, including but
|
|
33
|
+
not limited to compiled object code, generated documentation,
|
|
34
|
+
and conversions to other media types.
|
|
35
|
+
|
|
36
|
+
"Work" shall mean the work of authorship, whether in Source or
|
|
37
|
+
Object form, made available under the License, as indicated by a
|
|
38
|
+
copyright notice that is included in or attached to the work
|
|
39
|
+
(an example is provided in the Appendix below).
|
|
40
|
+
|
|
41
|
+
"Derivative Works" shall mean any work, whether in Source or Object
|
|
42
|
+
form, that is based on (or derived from) the Work and for which the
|
|
43
|
+
editorial revisions, annotations, elaborations, or other modifications
|
|
44
|
+
represent, as a whole, an original work of authorship. For the purposes
|
|
45
|
+
of this License, Derivative Works shall not include works that remain
|
|
46
|
+
separable from, or merely link (or bind by name) to the interfaces of,
|
|
47
|
+
the Work and Derivative Works thereof.
|
|
48
|
+
|
|
49
|
+
"Contribution" shall mean any work of authorship, including
|
|
50
|
+
the original version of the Work and any modifications or additions
|
|
51
|
+
to that Work or Derivative Works thereof, that is intentionally
|
|
52
|
+
submitted to Licensor for inclusion in the Work by the copyright owner
|
|
53
|
+
or by an individual or Legal Entity authorized to submit on behalf of
|
|
54
|
+
the copyright owner. For the purposes of this definition, "submitted"
|
|
55
|
+
means any form of electronic, verbal, or written communication sent
|
|
56
|
+
to the Licensor or its representatives, including but not limited to
|
|
57
|
+
communication on electronic mailing lists, source code control systems,
|
|
58
|
+
and issue tracking systems that are managed by, or on behalf of, the
|
|
59
|
+
Licensor for the purpose of discussing and improving the Work, but
|
|
60
|
+
excluding communication that is conspicuously marked or otherwise
|
|
61
|
+
designated in writing by the copyright owner as "Not a Contribution."
|
|
62
|
+
|
|
63
|
+
"Contributor" shall mean Licensor and any individual or Legal Entity
|
|
64
|
+
on behalf of whom a Contribution has been received by Licensor and
|
|
65
|
+
subsequently incorporated within the Work.
|
|
66
|
+
|
|
67
|
+
2. Grant of Copyright License. Subject to the terms and conditions of
|
|
68
|
+
this License, each Contributor hereby grants to You a perpetual,
|
|
69
|
+
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
|
|
70
|
+
copyright license to reproduce, prepare Derivative Works of,
|
|
71
|
+
publicly display, publicly perform, sublicense, and distribute the
|
|
72
|
+
Work and such Derivative Works in Source or Object form.
|
|
73
|
+
|
|
74
|
+
3. Grant of Patent License. Subject to the terms and conditions of
|
|
75
|
+
this License, each Contributor hereby grants to You a perpetual,
|
|
76
|
+
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
|
|
77
|
+
(except as stated in this section) patent license to make, have made,
|
|
78
|
+
use, offer to sell, sell, import, and otherwise transfer the Work,
|
|
79
|
+
where such license applies only to those patent claims licensable
|
|
80
|
+
by such Contributor that are necessarily infringed by their
|
|
81
|
+
Contribution(s) alone or by combination of their Contribution(s)
|
|
82
|
+
with the Work to which such Contribution(s) was submitted. If You
|
|
83
|
+
institute patent litigation against any entity (including a
|
|
84
|
+
cross-claim or counterclaim in a lawsuit) alleging that the Work
|
|
85
|
+
or a Contribution incorporated within the Work constitutes direct
|
|
86
|
+
or contributory patent infringement, then any patent licenses
|
|
87
|
+
granted to You under this License for that Work shall terminate
|
|
88
|
+
as of the date such litigation is filed.
|
|
89
|
+
|
|
90
|
+
4. Redistribution. You may reproduce and distribute copies of the
|
|
91
|
+
Work or Derivative Works thereof in any medium, with or without
|
|
92
|
+
modifications, and in Source or Object form, provided that You
|
|
93
|
+
meet the following conditions:
|
|
94
|
+
|
|
95
|
+
(a) You must give any other recipients of the Work or
|
|
96
|
+
Derivative Works a copy of this License; and
|
|
97
|
+
|
|
98
|
+
(b) You must cause any modified files to carry prominent notices
|
|
99
|
+
stating that You changed the files; and
|
|
100
|
+
|
|
101
|
+
(c) You must retain, in the Source form of any Derivative Works
|
|
102
|
+
that You distribute, all copyright, patent, trademark, and
|
|
103
|
+
attribution notices from the Source form of the Work,
|
|
104
|
+
excluding those notices that do not pertain to any part of
|
|
105
|
+
the Derivative Works; and
|
|
106
|
+
|
|
107
|
+
(d) If the Work includes a "NOTICE" text file as part of its
|
|
108
|
+
distribution, then any Derivative Works that You distribute must
|
|
109
|
+
include a readable copy of the attribution notices contained
|
|
110
|
+
within such NOTICE file, excluding those notices that do not
|
|
111
|
+
pertain to any part of the Derivative Works, in at least one
|
|
112
|
+
of the following places: within a NOTICE text file distributed
|
|
113
|
+
as part of the Derivative Works; within the Source form or
|
|
114
|
+
documentation, if provided along with the Derivative Works; or,
|
|
115
|
+
within a display generated by the Derivative Works, if and
|
|
116
|
+
wherever such third-party notices normally appear. The contents
|
|
117
|
+
of the NOTICE file are for informational purposes only and
|
|
118
|
+
do not modify the License. You may add Your own attribution
|
|
119
|
+
notices within Derivative Works that You distribute, alongside
|
|
120
|
+
or as an addendum to the NOTICE text from the Work, provided
|
|
121
|
+
that such additional attribution notices cannot be construed
|
|
122
|
+
as modifying the License.
|
|
123
|
+
|
|
124
|
+
You may add Your own copyright statement to Your modifications and
|
|
125
|
+
may provide additional or different license terms and conditions
|
|
126
|
+
for use, reproduction, or distribution of Your modifications, or
|
|
127
|
+
for any such Derivative Works as a whole, provided Your use,
|
|
128
|
+
reproduction, and distribution of the Work otherwise complies with
|
|
129
|
+
the conditions stated in this License.
|
|
130
|
+
|
|
131
|
+
5. Submission of Contributions. Unless You explicitly state otherwise,
|
|
132
|
+
any Contribution intentionally submitted for inclusion in the Work
|
|
133
|
+
by You to the Licensor shall be under the terms and conditions of
|
|
134
|
+
this License, without any additional terms or conditions.
|
|
135
|
+
Notwithstanding the above, nothing herein shall supersede or modify
|
|
136
|
+
the terms of any separate license agreement you may have executed
|
|
137
|
+
with Licensor regarding such Contributions.
|
|
138
|
+
|
|
139
|
+
6. Trademarks. This License does not grant permission to use the trade
|
|
140
|
+
names, trademarks, service marks, or product names of the Licensor,
|
|
141
|
+
except as required for reasonable and customary use in describing the
|
|
142
|
+
origin of the Work and reproducing the content of the NOTICE file.
|
|
143
|
+
|
|
144
|
+
7. Disclaimer of Warranty. Unless required by applicable law or
|
|
145
|
+
agreed to in writing, Licensor provides the Work (and each
|
|
146
|
+
Contributor provides its Contributions) on an "AS IS" BASIS,
|
|
147
|
+
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
|
|
148
|
+
implied, including, without limitation, any warranties or conditions
|
|
149
|
+
of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
|
|
150
|
+
PARTICULAR PURPOSE. You are solely responsible for determining the
|
|
151
|
+
appropriateness of using or redistributing the Work and assume any
|
|
152
|
+
risks associated with Your exercise of permissions under this License.
|
|
153
|
+
|
|
154
|
+
8. Limitation of Liability. In no event and under no legal theory,
|
|
155
|
+
whether in tort (including negligence), contract, or otherwise,
|
|
156
|
+
unless required by applicable law (such as deliberate and grossly
|
|
157
|
+
negligent acts) or agreed to in writing, shall any Contributor be
|
|
158
|
+
liable to You for damages, including any direct, indirect, special,
|
|
159
|
+
incidental, or consequential damages of any character arising as a
|
|
160
|
+
result of this License or out of the use or inability to use the
|
|
161
|
+
Work (including but not limited to damages for loss of goodwill,
|
|
162
|
+
work stoppage, computer failure or malfunction, or any and all
|
|
163
|
+
other commercial damages or losses), even if such Contributor
|
|
164
|
+
has been advised of the possibility of such damages.
|
|
165
|
+
|
|
166
|
+
9. Accepting Warranty or Additional Liability. While redistributing
|
|
167
|
+
the Work or Derivative Works thereof, You may choose to offer,
|
|
168
|
+
and charge a fee for, acceptance of support, warranty, indemnity,
|
|
169
|
+
or other liability obligations and/or rights consistent with this
|
|
170
|
+
License. However, in accepting such obligations, You may act only
|
|
171
|
+
on Your own behalf and on Your sole responsibility, not on behalf
|
|
172
|
+
of any other Contributor, and only if You agree to indemnify,
|
|
173
|
+
defend, and hold each Contributor harmless for any liability
|
|
174
|
+
incurred by, or claims asserted against, such Contributor by reason
|
|
175
|
+
of your accepting any such warranty or additional liability.
|
|
176
|
+
|
|
177
|
+
END OF TERMS AND CONDITIONS
|
|
178
|
+
|
|
179
|
+
APPENDIX: How to apply the Apache License to your work.
|
|
180
|
+
|
|
181
|
+
To apply the Apache License to your work, attach the following
|
|
182
|
+
boilerplate notice, with the fields enclosed by brackets "[]"
|
|
183
|
+
replaced with your own identifying information. (Don't include
|
|
184
|
+
the brackets!) The text should be enclosed in the appropriate
|
|
185
|
+
comment syntax for the file format. We also recommend that a
|
|
186
|
+
file or class name and description of purpose be included on the
|
|
187
|
+
same "printed page" as the copyright notice for easier
|
|
188
|
+
identification within third-party archives.
|
|
189
|
+
|
|
190
|
+
Copyright [yyyy] [name of copyright owner]
|
|
191
|
+
|
|
192
|
+
Licensed under the Apache License, Version 2.0 (the "License");
|
|
193
|
+
you may not use this file except in compliance with the License.
|
|
194
|
+
You may obtain a copy of the License at
|
|
195
|
+
|
|
196
|
+
http://www.apache.org/licenses/LICENSE-2.0
|
|
197
|
+
|
|
198
|
+
Unless required by applicable law or agreed to in writing, software
|
|
199
|
+
distributed under the License is distributed on an "AS IS" BASIS,
|
|
200
|
+
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
201
|
+
See the License for the specific language governing permissions and
|
|
202
|
+
limitations under the License.
|
py1815-0.1.0/NOTICE
ADDED
|
@@ -0,0 +1,10 @@
|
|
|
1
|
+
py1815
|
|
2
|
+
Copyright 2026 DER Security Corp
|
|
3
|
+
|
|
4
|
+
This product includes software developed at DER Security Corp.
|
|
5
|
+
|
|
6
|
+
Licensed under the Apache License, Version 2.0 (the "License"); you may not
|
|
7
|
+
use this file except in compliance with the License. You may obtain a copy of
|
|
8
|
+
the License at
|
|
9
|
+
|
|
10
|
+
http://www.apache.org/licenses/LICENSE-2.0
|