profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/shred/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.

shred/acme4j 392

Java client for ACME (Let's Encrypt)

shred/commons-suncalc 68

Calculate sun and moon times in Java

shred/commons-captcha 10

Generator for simple captcha images

shred/flattr4j 10

Java and Android client for Flattr API

shred/dustycase 7

3D printed frame for a Particulates Sensor

shred/fritzswitch 5

Small python command line tool for controlling Fritz!Box home automation

shred/acarsclient 3

A Java client for acarsd

shred/cilla 3

Weblog and gallery software written in Java

shred/a4000-bom 2

Amiga 4000D Rev B Bill of Material

shred/commons-pdb 2

Read PalmOS PDB files with Java

push eventshred/shariff-backend-java

Richard Körber

commit sha 99ff764d2cf9f2929cd8c7f17f05e9bcbdfa6685

Update to Facebook API v12.0

view details

push time in 2 days

issue commentshred/commons-suncalc

[Question] Is there some way to get latitude and longitude in Java?

Java itself does not provide a geolocation API. This is why suncalc is just using double for latitude, longitude, and height.

What you need is some kind of GPS hardware connected to your system. Most GPS receivers use the NMEA 0183 protocol, so you can use something like Java Marine API for parsing the NMEA sentences from your GPS device. Depending on how the GPS hardware is connected (e.g. serial port, USB), you might also need a library for the hardware communication. I have never tried that, so I cannot provide more help.

sblantipodi

comment created time in 12 days

issue commentshred/acme4j

[Feature request / acme4j-smime] Add support for S/MIME validation

Thank you... Yes, S/MIME validation and signature should be part of acme4j. I will have a look into that.

augjoh

comment created time in a month

startedendofexclusive/deniser

started time in a month

startedprimekeydevs/ejbca-ce

started time in a month

issue closedshred/acme4j

RFC8823: acme4j response does not match CA expectation

Currently only dns identifiers are supported. Please add support for email identifiers, too. See RFC8823 (https://datatracker.ietf.org/doc/html/rfc8823) for more information.

A server implementation for testing can be found here: https://gitlab.com/platynum/certification-authority

closed time in a month

augjoh

issue commentshred/acme4j

RFC8823: acme4j response does not match CA expectation

I agree. But it seems that in the ACME mailing list no one sees a need to further clarify that problem, e.g. in an RFC8823 errata. I am quite sure that I will be having this discussion again some day.

Anyway, thank you for your report!

augjoh

comment created time in a month

issue commentshred/commons-suncalc

Add Dawn and Dusk times

There are different twilights (civil, nautical and astronomical) supported by suncalc. You just need to set the desired twilight using the .twilight() setter, and then you will get the corresponding dawn and dusk times by invoking .getRise() and .getSet().

Also see:

  • https://shredzone.org/maven/commons-suncalc/usage.html#twilight
  • https://shredzone.org/maven/commons-suncalc/examples.html#twilight

Does it resolve your issue?

FJBDev

comment created time in a month

issue commentshred/acme4j

RFC8823: acme4j response does not match CA expectation

Alexey Melnikov has answered in the mailing list: https://mailarchive.ietf.org/arch/msg/acme/KusfZm3qC50IfcAAuTXtmbFK0KM/

I can confirm that my intent was to suggest straight string concatenation without any base64url-decode and re-encoding.

This means that acme4j handles the challenge according to the intention of the RFC author, and (sorry to say that) the bug is on the CA side. :wink:

However, I am glad that we can close this issue with certainty.

augjoh

comment created time in a month

issue commentshred/acme4j

RFC8823: acme4j response does not match CA expectation

As Brian Sipos said in his response:

[...] RFC 8823 does not make any requirements about the content of the "token-part2" text value. The fact that the example looks like base64url encoding implies that, but I don't see any requirement on the token-part2 generation other than its minimum entropy.

So actually, <token-part2> could be anything, and mixing a base64url encoded <token-part1> with a stringish <token-part2> might be the intention.

Well, I guess we can agree that RFC8823 leaves a lot of room for interpretation, as we are both (independently) not certain about how to do proper concatenation. :smiley: I hope that Alexey Melnikov (as the author of the RFC) can shed some light on it.

augjoh

comment created time in a month

IssuesEvent

issue commentshred/acme4j

[Feature request] Add support for S/MIME certificates (RFC8823)

First of all, thank you for the detailed explanation! It was really helpful for reproducing the problem.

Actually, I have anticipated this issue...

According to RFC-8823, the CA needs to generate two tokens (Token Part 1 and Token Part 2). Unfortunately the RFC is not very clear about how the two parts are then supposed to be concatenated by the client. Section 3 only says:

  1. The ACME client concatenates "token-part1" (received over email) and "token-part2" (received over HTTPS [RFC2818]) to create the ACME "token" and calculates keyAuthorization (as per Section 8.1 of RFC8555).

There are two possible ways of concatenation.

  • Both token-parts are base64-decoded and the byte arrays are concatenated. The result is then base64url-encoded again, in order to compute the key-authorization.

  • Both token-parts are just string-concatenated, and the result is then used for key-authorization.

Both ways give different results, because of the padding bits that may be appended by base64 encoding. Sadly the RFC gives no concrete example of a concatenation so one could compare the own implementation with an expected result.

I had already raised this question in the ACME mailing list in June: https://mailarchive.ietf.org/arch/msg/acme/mOtPJpJHmmJeuzGBIaHuDcX8LBI/

Brian Sipos then gave good arguments for the string concatenation, and deemed the RFC-8823 text sufficient to explain this: https://mailarchive.ietf.org/arch/msg/acme/suw60485gKpcP9Cx5tl9gE1SQQI/

I got no other answers that were relevant. For this reason, acme4j uses string concatenation for computing the key-authorization value. Assuming that, like in your example:

token 1    = "5T6P7VjzlZO_LkBgHYBwpQmYsnXkPpZTikh_DkJAMM0"
token 2    = "l0Euldt78kNFEmb5K3k-rv4fGsSgvBBlDxUQO_IbmFk"
thumbprint = "gAJVFtivkss40JqEsHy2v6r6oxd8xrkVaF3Z1VzkpIo"

The string concatenation gives:

string-concat = "5T6P7VjzlZO_LkBgHYBwpQmYsnXkPpZTikh_DkJAMM0l0Euldt78kNFEmb5K3k-rv4fGsSgvBBlDxUQO_IbmFk"
key-auth      = "5T6P7VjzlZO_LkBgHYBwpQmYsnXkPpZTikh_DkJAMM0l0Euldt78kNFEmb5K3k-rv4fGsSgvBBlDxUQO_IbmFk.gAJVFtivkss40JqEsHy2v6r6oxd8xrkVaF3Z1VzkpIo"

response      = "OLzGVBMykMOx0F8OSZaf94jXpFctHswLUzbTTqVF1cM"
              = d4b4a416dd99c00d4948ec6a50a59bc28e44d96ba8a589c7d0e4a348720f99cc

This is what acme4j gives as response to your CA. Your CA however seems to expect a byte array concatenation:

array-concat = "5T6P7VjzlZO_LkBgHYBwpQmYsnXkPpZTikh_DkJAMM2XQS6V23vyQ0USZvkreT6u_h8axKC8EGUPFRA78huYWQ"
key-auth     = "5T6P7VjzlZO_LkBgHYBwpQmYsnXkPpZTikh_DkJAMM2XQS6V23vyQ0USZvkreT6u_h8axKC8EGUPFRA78huYWQ.gAJVFtivkss40JqEsHy2v6r6oxd8xrkVaF3Z1VzkpIo"

response     = "DZsxvV81Xp6D9DoBIV7QXiIhgve03G1l9bR3DAQILOM"
             = 0d9b31bd5f355e9e83f43a01215ed05e222182f7b4dc6d65f5b4770c04082ce3

Note how string-concat and array-concat are different. This is the only reason for the different response. If acme4j were to use byte array concatenation, it would give the result that is expected by your CA.

It is a difficult situation now, because in my oppinion it is unclear whether your CA or acme4j implements that RFC incorrectly. There are good arguments on both sides, and personally I would even favor byte array concatenation. But the RFC itself (sadly) gives no further clues.

I have just contacted the author of RFC-8823 and asked him for clarification. I will report back as soon as I got an answer.

augjoh

comment created time in a month

startedchrisly42/mc68000-asm-plugin

started time in a month

issue closedshred/commons-suncalc

Different results are given for the same solar event depending on the date-time given as input

Hi, and thank you for providing this library. I'm using it to provide solar (and lunar) calculations in a Hebrew calendar library for Clojure. As I'm not a Java developer I apologize for only being able to provide feedback from a Clojure perspective.

I have a function named calculate-sun-events:

(defn- calculate-sun-events
  [lat lon date]
  (let [tz (tz? date)]
    (-> (SunTimes/compute)
        (.on date)
        (.at lat lon)
        (.oneDay)
        (.timezone (str tz))
        (.execute))))

Depending on what date I provide, I get slightly different results for the same solar events:

(calculate-sun-events 58 12 (go-back (t/hours 6) (now)))
;; => #object[org.shredzone.commons.suncalc.SunTimes 0x5884dce1 "SunTimes[rise=2021-08-06T05:16:12.951668+02:00[Europe/Stockholm], set=2021-08-05T21:20:50.951668+02:00[Europe/Stockholm], noon=2021-08-06T13:17:40.951668+02:00[Europe/Stockholm], nadir=2021-08-06T01:18:17.951668+02:00[Europe/Stockholm], alwaysUp=false, alwaysDown=false]"]
(calculate-sun-events 58 12 (go-back (t/hours 10) (now)))
;; => #object[org.shredzone.commons.suncalc.SunTimes 0x24c96f8 "SunTimes[rise=2021-08-06T05:16:13.347419+02:00[Europe/Stockholm], set=2021-08-05T21:20:51.347419+02:00[Europe/Stockholm], noon=2021-08-05T13:17:48.347419+02:00[Europe/Stockholm], nadir=2021-08-06T01:18:18.347419+02:00[Europe/Stockholm], alwaysUp=false, alwaysDown=false]"]

lat is 58, and lon is 12 in both examples above. date is 6 hours ago and 10 hours ago since the current system time as a ZonedDateTime object. Looking at the events I would expect them to be exactly the same in both examples since they occur during the same day, but there are slight differences.

Could this be a bug?

closed time in a month

johanthoren

issue commentshred/commons-suncalc

Different results are given for the same solar event depending on the date-time given as input

You're welcome! I'm glad I could clarify it.

johanthoren

comment created time in a month

issue commentshred/commons-suncalc

Different results are given for the same solar event depending on the date-time given as input

Thank you for your report. Yes, one could expect that the result is exactly the same because it is the same event.

However, astronomical calculations are quite complex. This library uses approximation algorithms for calculation, to keep the CPU load low. Depending on the preconditions (e.g. starting time of the time window), the results will then be slightly different due to rounding errors.

Please also see the accuracy section in the ReadMe file. This library was never designed to be precise down to a second, but only to about a minute. This is given in your example, so no, it's not a bug. :slightly_smiling_face:

You can use LocalDateTime.truncatedTo() to truncate the result to full minutes. It should give consistent results.

As a side node: To get meaningful sun times in a precision of a second or less, one would also have to consider factors like air pressure, the current temperatures in different atmospheric layers, topological obstacles (like mountains or large buildings) etc.

johanthoren

comment created time in a month

issue closedshred/acme4j

Does acme4j support “alternate” link relation?

Hello. I have a question avove. Do you aware it?

Here more info about it - https://community.letsencrypt.org/t/issuance-on-r3-vs-x3-is-this-configurable/138496

closed time in 2 months

doom369

issue commentshred/acme4j

Unable to update challenge :: authorization must be pending

Issue has been fixed in the meantime. I forgot to close the issue.

AmadeusSys

comment created time in 2 months

issue closedshred/acme4j

Unable to update challenge :: authorization must be pending

Order order = login.bindOrder(orderLocation);

for (Authorization auth : order.getAuthorizations()) {
     authorize(auth);
}

challenge.trigger();

Result JSON: {"type":"urn:ietf:params:acme:error:malformed","detail":"Unable to update challenge :: authorization must be pending","status":400}

closed time in 2 months

AmadeusSys

issue commentshred/acme4j

[Feature request] Add support for S/MIME certificates (RFC8823)

S/MIME is supported since acme4j v2.12. You need to add the acme4j-smime module as dependency though. It is a separate module because it uses javax.mail and thus requires a JavaMail implementation in the classpath.

The acme4j-smime module provides EmailIdentifier as email identifier, and also supplies helper methods for parsing challenge emails and generating response emails. Please note that S/MIME support is experimental at the moment.

More about S/MIME support is documented here: https://shredzone.org/maven/acme4j/challenge/email-reply-00.html

Thank you for the test server link. It supports both S/MIME and STAR, so I can use it to end the experimental state of both extensions, finally.

I'm closing the issue because it seems that everything you need is already present. If something is missing, feel free to reopen it.

augjoh

comment created time in 2 months

issue closedshred/acme4j

[Feature request] Add support for S/MIME certificates (RFC8823)

Currently only dns identifiers are supported. Please add support for email identifiers, too. See RFC8823 (https://datatracker.ietf.org/doc/html/rfc8823) for more information.

A server implementation for testing can be found here: https://gitlab.com/platynum/certification-authority

closed time in 2 months

augjoh

created tagshred/pynaroma

tag0.1.0

Convert Amiga ROM images to BIN dumps, or vice versa

created time in 2 months

push eventshred/pynaroma

Richard Körber

commit sha ef0f28dad4e02c8d54a94e389d63e061ee12f67a

Fix rom2bin error in 16-bit mode

view details

push time in 2 months

create barnchshred/pynaroma

branch : master

created branch time in 2 months

created repositoryshred/pynaroma

Convert Amiga ROM images to BIN dumps, or vice versa

created time in 2 months

issue commentshred/fritzswitch

PermissionError: access denied

No problem at all. I'm glad that there was an easy solution. :smile:

Schlunze

comment created time in 2 months

issue commentshred/fritzswitch

PermissionError: access denied

I don't think it's related to a Python update.

I have just tested the script with the latest Python 3.9.6 against a FritzBox 7590 with the latest firmware 07.27, and with a dedicated user that has only "Smart Home" permissions. It was working fine. :slightly_smiling_face:

The error says that fritzswitch could not create a session with the FritzBox, so my guess is that something in the FritzBox configuration might have changed. Can you try a different FritzBox user for a test? Or can you just set a fresh password for your smart home FritzBox user? (I guess you already have checked the permissions.)

Schlunze

comment created time in 2 months

push eventshred/maestix

Richard Körber

commit sha 2bc6f0dcaa582cd2da493ef1edc028ca13622703

Replace self-made timer delay with amiga.lib call

view details

Richard Körber

commit sha ada46c487ad57e2d334632f80bcf44e5f11a0480

Realtime FX: D6 and D7 are aggregation registers now

view details

Richard Körber

commit sha 891e356406c12fb2f200557a51c077088171abac

Refactor hardware lock

view details

Richard Körber

commit sha aa74e0687ce284010ca938fdb2f362b461531c9c

Fix syntax error in fd file

view details

push time in 2 months

push eventshred/maestix

Richard Körber

commit sha 4bdc357b0ef6cfa73c3af7db537d869bd165e977

Add missing private function in .fd file

view details

Richard Körber

commit sha ab5429216eec3cb30efc455ee30fbbd299bbb5f6

Document usage of sign flag

view details

push time in 2 months

push eventshred/maestix

Richard Körber

commit sha 8ab3ef4e4270bcb3c50e037c30119477cedf5f07

Add q to faq

view details

Richard Körber

commit sha 436d1b2670d152f59de6db2e7c032b0ff78fd7c2

Fix typo

view details

push time in 2 months